Xcode

Developing for iOS 9: Supporting Dynamic Type and Responding to User Changes

Dynamic Type was introduced with iOS 7 as a way for developers to abstract font details like typeface, size, weight, and kerning into a series of pre-defined font categories called Text Styles. 

In this post, you'll learn how to support Dynamic Type in your app including how to properly respond to user text size changes.

Developing for iOS 9 - canOpenURL: changes

I ran into an issue earlier this evening when my new iOS 9 app was sending me to twitter.com instead of opening the Twitter app. There doesn't seem to be much mention about it in either the WWDC sessions or online.

This used be perfectly safe code (pardon my obj-c):

if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"twitter://user?screen_name=screenshot_app"]]) {
[[UIApplication sharedApplication] openURL: [NSURL URLWithString:@"twitter://user?screen_name=screenshot_app"]];
} else {
[[UIApplication sharedApplication] openURL: [NSURL URLWithString:@"http://www.twitter.com/screenshot_app"]];
}

In fact, it still is with one gotcha via use your loaf. Apps linked against iOS 9.0 and later will have to white list app schemes they want to use with a new LSApplicationQueriesSchemes key in their Info.plist (That key maps to an array of strings).

In theory, this new block will stop apps from building a list of apps already installed on a device by querying through a lost of known URL schemes using canOpenURL. Presumably, if you can't explain why you're including over 100 schemes in LSApplicationQueriesSchemes, you'll be rejected during app review.

iOS 8 apps running on iOS 9 will apparently work as expected until they cross a 50 scheme threshold at which point canOpenURL: will return an error.

When updating to iOS 9, be sure to add LSApplicationQueriesSchemes to your Info.plist. A 'Find in Workspace...' for canOpenURL will show every instance where you're calling a url scheme.

Debugging Apps on Apple Watch

With iOS 8.2 beta and WatchKit, we now have a way to create apps (sort of) for Apple Watch. With Apple Watch not actually going on sale until some time in 2015, developers can only test their apps in the Watch simulator on their Mac.

This isn't the first time developers are tasked with creating software for a device they haven't seen in person. In 2010, developers began writing apps for iPad which, at that time, wouldn't ship until months later.

There's nothing wrong with this approach. In fact, it's great that Apple gives early API access to developers so their apps will be ready on launch day.

One issue we encountered while testing on iPhone OS 3.2 was we had little knowledge of the original iPad's performance capabilities. We over-estimated what that device was capable of. Software that ran smoothly in the Simulator on a Mac with access to, at that time, a blazing-fast dual-core Intel CPU ran slow and choppy on the iPad's A4. Surprise.

With iOS 8.2's WatchKit, it's a little different this time around. Instead of running native apps on the Watch, we're only able to create extension-like software that runs primarily on iPhone. By using the iPhone's processor, Apple is able to maximize Apple Watch battery life. In addition, WatchKit doesn't yet allow for the creation of full/native Watch apps as you would think of them for the iPhone.

Native Apple Watch apps are coming sometime next year, most likely at June's WWDC. And that's when the Watch Simulator won't be enough and developers will need to test their apps on an actual device. 

So how will that actually work? With iPhone and iPad app development, you connect your iOS device to your Mac and run a project in Xcode. But, the Apple Watch doesn't have a Lightening port.

While it's somewhat of a mystery, my best guess is Xcode will bring back wireless device testing. It was a seldom talked about feature in Xcode 5 that took some tinkering to enable, but it used to be possible to wirelessly test an app on an iOS device without connecting it directly to your Mac via USB. At some point, it seems, the Xcode Team removed the feature as I can't find any trace of it in Xcode 6.1.

The possibility of wirelessly debugging an app on a device that I don't have to plug in to a computer is enticing. I would also imagine any content syncing to the device will be done wirelessly through iTunes.

If that's true, this is one developer that hopes wireless testing/debugging is supported for all iOS devices, not just the Apple Watch.

Creating iSource 2.5 for iOS 8

Tonight I finished work on the latest version of iSource APA (2.5). It supports and now requires iOS 8 and is currently awaiting review.

iOS 8 brings great new features and fixes many bugs introduced with iOS 7's interface redesign. Along with iOS 8 is Swift and Xcode 6.

The biggest features that users will notice first are Today and Sharing widgets. Shortly after WWDC14, I decided not to include support for these in apps that didn't absolutely need them. In the case of iSource, what was I going to include in a Today widget? A fancy slogan? An inspirational quote? Nope. I didn't want to take up people's time with a Today widget unless it provided real value.

Take the Clear Today widget. If you remove all the content in the app, it decides to give you a *cough* inspirational quote. I didn't ask for it but there it is. 

You also may notice a beta version of the Today widget I'm including in Bug Trackr 2.0. It tells you what you need to know while using the minimum amount of screen real estate possible.

Below, you'll see Pedometer++'s Today widget. Short and to the point, I like it.

iOS 8's Today view is still very much a UI playground and I realize developers are often scratching their heads about what to include there. Sometimes, the best thing to do is do nothing at all. 

Sharing widgets are another story all together. I would love to be able to create a resource share sheet, basically the same text entry you see in the app, but available through other apps. There would be a relatively low amount of apps you would want access to iSource's Share widget in but it could still be useful.

The problem is iOS 8's sharing data flow paradigm. The way iOS 8 works is that you select the data you want to share, tap the share button, and select the place or service you want to share to. An iSource share sheet would make sense in a scenario where the user, from anywhere in iOS, wants to add an entry, they bring up the iSource Share Sheet and enter in the resources parameters. But that reverses Apple's data flow in iOS 8's share sheets. It would be confusing to the user even if Apple approved it in App Review.

So for now, we're going to stay away from Today and Sharing widgets.


Also new in iSource 2.5 are completely redesigned resource icons. They fit in a whole lot better with the iOS ⅞ aesthetic and they're included as @1x/@2x/@3x (and @4x for then that day arrives) assets. The icon redesigns were something I had started last year when I added more assets but, since the introduction of @3x assets (which I didn't have), I decided to start from scratch on a new set.

With this version and unrelated to iOS 8 I decided to reintroduce landscape support for iPhone. This was only because of the new display sizes in the iPhone 6 and iPhone 6 plus. In the 1.0 version of iSource, I enabled landscape support because text entry was done directly in the table view. When I added the Entry Sheet around iSource 2.0, I removed landscape because springs and struts in Interface Builder didn't allow me to configure the sheet view as I wanted when displayed in landscape with the keyboard visible. With the addition of Size Classes in Xcode 6, its now possible for me to create different configurations of the entry sheet based on its size class.

Top right you'll see the traditional version of the Entry Sheet in iSource 2.5, complete with blurred background. Bottom right is the Entry Sheet in it's new landscape configuration. Nice eh? Thanks Size Classes!


At WWDC14, I was highly interested in playing around with iOS 8's new Embedded Framework support. iSource 2.5 includes the new iSourceKit framework and it's where I've put a lot of code and resources that I share between iSource APA and MLA. Without going into too much boring nitty gritty about maintaining two versions of the same app, frameworks are a godsend. For code within iSourceKit, I've been able to cut debug time in half and every minute saved debugging is one I can now spend on making great feature. Thank you Embedded Frameworks engineers at Apple!

iOS 8 App Extension Development Tips

Great insight from Tom Harrington on developing iOS 8 app extensions. For developers, Extensions are still very much uncharted territory and Tom breaks down some of the gotchas you'll come across when in Xcode.

Recently I’ve been working on some iOS 8 app extensions, and I’ve run into a few non-obvious details that might come in handy for anyone else in the same situation. Some of the following relates to bugs still in the system, and so will probably only be relevant for a limited time.
— http://www.atomicbird.com/blog/ios-app-extension-tips?utm_campaign=iOS_Dev_Weekly_Issue_167&utm_medium=email&utm_source=iOS%2BDev%2BWeekly