Just Imagine →

Ish Shabazz:

Imagine standing in front of a stove with two pots before you. The pot on the left contains liquid that has been boiling for about five hours. The pot on the right also contains liquid but the burner was never on, and as such, is room temperature. Six minutes ago, the fire was turned off on the boiling pot. When this happened the liquid started to cool, however, it continued to visibly be boiling for another four minutes. So currently, neither pot has a fire under it and the pot on the left hasn’t been visibly boiling for two minutes.

Imagine placing your right hand in the pot on the right and your left hand in the pot on the left. Do you expect to feel a difference?

→ July 13, 2016 at 7:44 am

Continuous for iOS

Continuous is a new app for doing real app development on the iOS using C# and F# written by the same developer who wrote Calca. The cool thing about it is that it has access to the built in iOS frameworks, so the app can be used to build real iOS apps right from your iPad1.

I don’t have much use for Continuous myself since I prefer to do my development in Swift, but I am excited to see more apps like this hit the App Store. Apps like Continuous and Pythonista (which also has access to iOS frameworks, this time in Python) show that there is a market for this type of app. People want to be able to use their iPads for development.

These apps show that it is possible to have a good IDE running on iOS2.

  1. I listened to a podcast a few years back where the developer of Calca mentioned that the app was written in C#. I remember thinking it was a weird language choice at the time, but I have since learned that it is a relatively popular language to do iOS development in. Plus, I can’t argue with the results: Calca is an incredible app. ↩
  2. One of the things Apple did with Xcode 8 was make the app take up a lot less disk space. It later occurred to me that part of the motivation for that could be to get it running on devices that don’t have as much storage space as most Macs. You know, like an iPad? ↩

→ July 12, 2016 at 8:05 am

RadarScope 3.1

RadarScope 3.1 is out today. There are a few small fixes1, but the big change is that RadarScope Pro is now an auto-renewing subscription. Switching to auto-renewing is good for everyone: customers will be able to more easily restore across devices and we will get an extra 15% commission when a user has been subscribed for more than a year.

Most apps are not able to take advantage of the new auto-renewing subscription policy changes until iOS 10 launches this fall, but weather apps are a special case and are able to use them now.

If you don’t want to automatically renew, you can subscribe and then go to your subscription settings and unsubscribe. You will still be able to use the subscription for the year it was purchased for.

  1. My favorite is the new selected appearance of buttons on the map. ↩

→ July 11, 2016 at 9:58 am

Allow Swift types to provide custom Objective-C representations

Joe Groff put together a proposal to import any Objective-C interfaces that use id to Swift as Any instead of AnyObject. This would basically allow Objective-C types to be bridged as value types more easily in Swift (and vice-versa).

The part that caught my attention the most was this.

Bridged value types with established bridging behavior, such as String, Array, Dictionary, Set, etc., should continue to bridge to instances of their corresponding idiomatic Cocoa classes, using the existing internal _ObjectiveCBridgeable protocol. The set of bridged types can be extended in the Swift implementation (and hopefully, eventually, by third parties too) by adding conformances to that protocol.

I am pretty excited about the idea of being able to bridge our own value types to different Objective-C representations. We are using Swift for all of our new code at WDT, but not all of our clients are. We have frameworks that both us and clients use that we are currently rewriting in Swift; but we cannot take complete advantage of Swift’s feature set because our framework needs to work in Objective-C too1.

I did a quick test and having our own value types conform to _ObjectiveCBridgeable does let me transition them to Objective-C NSObject subclasses automatically, but Joe warned me that using it could lead to bugs because the compiler is expecting a closed set up types to conform to that protocol.

The last official news that we heard on this subject was a proposal to open up the _ObjectiveCBridgeable protocol being deferred from Swift 3. This new proposal does not include opening that protocol up yet, but it is a step in that direction.

Update 7/6: This proposal is in review here.

  1. So basically no public structs or enums. ↩

→ July 1, 2016 at 8:53 pm

Swift vs. Obj-C: Target Conditionals

Justin Williams put together a list of what platform macros from TargetConditions.h trigger each specific platform. The results are a mess. The worst one is that TARGET_OS_MAC will target all of Apple’s platforms (macOS, iOS, watchOS, & tvOS) and TARGET_OS_IPHONE is everything except macOS.

This is one of the most underrated improvements in Swift. Instead of

#if TARGET_OS_IPHONE
  // iOS code
#else
  // macOS code
#endif

we can use something more like

#if os(macOS)
  // macOS code
#endif

The nice thing here that you don’t have to worry about if you are running on the simulator or not1.

Even better, starting with Swift 3 you can check for the existence of a framework. This is useful for frameworks that are supported on multiple platforms.

#if canImport(UIKit)
  // iOS, tvOS, & watchOS
  import UIKit
  let color: UIColor
#elseif canImport(AppKit)
  // macOS
  import AppKit
  let color: NSColor
#endif

These are small improvements, but they make writing code that runs on multiple platforms a lot easier.

  1. There is a separate check you can still make if you need to know that. ↩

→ July 1, 2016 at 4:57 pm