iOS 9

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.

Text Entry and the new Apple TV

The Siri remote on the new Apple TV is fantastic for scrolling through a UI and playing a new class of games thanks to the built-in gyroscope and touch pad but it's lousy for text entry.

But the new Apple TV hardware remote is no keyboard replacement. In fact, it's a step backwards from the last-generation Apple TV. With the previous Apple TV, you could use your iOS device's keyboard to enter text via the IOS Remote App. If a text field appeared, just open the Remote app and use the on-screen keyboard.

To enter text on this Apple TV, you have to manually enter each character with the hardware remote like a dog. Curiously, the new Apple TV doesn't support the Remote app at all and other than for the initial setup process, Apple TV has no use for your iPhone or iPad. Surely though, you could pair a Bluetooth keyboard? Nope.

For more about the frustrations in these early days of Apple TV 2015, take a look at Jason Snell's piece for Macworld.

What gives?

At 5 days after launch and more than a month of using the Dev kit, my best guess is a conscious decision by Apple to limit text entry on the new device. Remember that the new Apple TV is running a custom version of iOS 9.0. Devs were encouraged to port games and the process was relatively straight forward. Other apps like Speed Test and Plex have arrived on the App Store too. But what about Twitter, Pages, or Things?

Apple has made it nearly impossible to create or port apps that require more text entry than a basic search term or password. I mention Pages because it is technologically possible for the Apple TV's A8 SoC to run the iOS version of Pages. The market should decide if Text Editors on Apple TV is a good idea, not Apple.

Either Apple doesn't feel text editors have a place in the living room or decent text entry is an afterthought. I would believe the latter, that maybe it's coming in a future software update, if the Remote had never existed and we had not been able to pair a Bluetooth keyboard in the past. It's not a misstep, in tvOS it's by design. Things may change in tvOS 2 but I'm not holding my breath.

Screenshot++ - Implementing Peek and Pop and Home Screen Quick Actions for iPhone 6s

Screenshot++DualiPhone6Promo.png

Screenshot++ 2.1 is about to enter beta testing and includes support for Peek and Pop and Home Screen Quick Actions for iPhone 6s and iPhone 6s Plus.

This is the first app I've updated to take advantage of these new features and I think they're awesome. Peeking is fast and fluid and a definite time saver for users.

Both of these new 6s features are relatively easy to implement if you've been using NSUserActivity and either table or collection views in your app. For a guide on implementing Peek and Pop, check out Apple's UIViewControllerPreviewing API sample code. For Home Screen Quick Actions, I used 3D-touch on Github to get started.

For Peeking into a UICollectionViewCell, set the sourceRect property on UIViewControllerPreviewing to that of the selected cell (I assume this is the same for UITableViewCell but I haven't tried Peek with a tableView yet.) Something like this:

UICollectionView *cv = self.collectionView;
UICollectionViewLayoutAttributes *attributes = [cv layoutAttributesForItemAtIndexPath:_openScreenshotCellIndexPath];

CGRect cellRect = attributes.frame;
[previewingContext setSourceRect:cellRect];
_assetViewController.preferredContentSize = CGSizeMake(asset.pixelWidth, asset.pixelHeight);

If you have any questions leave a comment or find me @wesleydyson on Twitter. Check out Screenshot++ and join the beta!

On Content Blockers

With the release of iOS 9, Apple made it easy to download and install a new category of apps called Content Blockers. These are extensions that run in Safari that tell the browser not to load parts of a website. Some can be used to stop a site from tracking you, some stop comments from ever being displayed, but the most controversial are Content Blockers that block ads.

Marco Arment, a fellow iOS dev who I deeply respect, launched his own Content Blocker called Peace earlier this week. He's since removed the app from sale. Read about Marco's decision.

There is nothing nice about blocking ads on a website. With an ad-blocking extension enabled, ads are never loaded when you view a webpage. For the site owner, that's ad revenue they will never receive.

While terrible for publishers, Content Blockers are a win-win for users. With ads disabled, pages load faster, use less data to fully load, and their activities on a site can't be tracked using conventional methods. In my testing with Peace, pages in Safari loaded noticeably faster. In fact, the difference was staggering, especially at the Verge and iMore - 2  of the worst tech blog offenders.

The content publisher/reader relationship has always been free content with ads. Ads used to be lightweight objects. Today, they're frequently larger than the website and all original content combined. That's disgraceful.

For the relationship to work, each side must trust each other. With massive ads, constant tracking, and poor performance, content publishers have lost the trust of readers. With iOS 9, readers now have the power to fight back against an ad/tracking industry that's become too big for its britches.

As a result of Content Blockers becoming widely adopted, some sites will shut down and that's a damn shame. Sites will, and have already, lose money. Worse, the more publishers lash out at their readers, the more they run the chance of those readers never coming back.

The ball is now with content publishers and site owners. My advice? Don't blame your readers. Take responsibility for your tracking shenanigans, slowing user's devices, and having no regard for their bandwidth/data caps. Switch to an ad provider that serves lightweight, ethical ads (they exist). Be an example to the rest of the industry and let your readers know you're leading the charge!

It is the content publisher's responsibility to regain the trust of their readers. Until then, we'll continue to say no to the status quo.

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.

Screenshot++ and new Apple Hardware

I'm currently finishing development on Screenshot++ 2.0. I decided this version will also support iPad Pro sized screenshots and be available before the new iPad actually ships to customers in November.

Its important that Screenshot++ users be able to interact with the iPad Pro's massive screenshots from day 1. It's also a little frightening that I won't be able to properly test this feature on an actual device before official launch day. Chicken or the egg?

I'm looking into whether screenshots from the new Apple TV can be supported in the app. Can you take screenshots of the Apple TV's output without the simulator? If so, where do the files go? Screenshots from Apple Watch worked out well because a screenshot taken on the Watch is moved to the user's iPhone soon after creation. I'll have more info about screenshots from Apple TV in a later post.

Because I don't want to cause major delay in shipping Screenshot++ 2.0 with iOS 9 support, I'll be adding iPhone 6s features in a 2.1 release later this fall.

--WD

Screenshot++ 1.2 Now Available

I'm pleased to announce that Screenshot++ 1.2 is now available on the App Store! It includes support for screenshots from Apple Watch, Quick Actions for automating complex actions, keyboard shortcuts, and UI enhancements.

A big thank you to all our beta testers for their valuable feedback! If you would like to help the next version of Screenshot++, we'll be running another beta for our next version soon.

Screenshot++ 2.0 is already in development with support for new features in iOS 9 as well as a new Dashboard. Stay tuned for more info!

If you love Screenshot++, please take a moment to rate and review us in the App Store. It really helps!

Learn more about Screenshot++

Functional High Ground Retort

I fear that Apple’s leadership doesn’t realize quite how badly and deeply their software flaws have damaged their reputation, because if they realized it, they’d make serious changes that don’t appear to be happening. Instead, the opposite appears to be happening: the pace of rapid updates on multiple product lines seems to be expanding and accelerating.
— Marco Arment, marco.org

Much has been written about Marco Arment's piece from Monday night, some constructive, most sensationalist drivel. The fundamental assumption here is that Apple's recent software riddled with bugs and was shipped before it was ready. I disagree.

I used OS X from Jaguar to Yosemite, iOS 1.0 through 8.1, and every release in between. Are there more bugs in today's software than 2007 or 2004?

Apple's software, like any piece of software, has always had bugs. iOS 7.0 at launch was unstable at the best of times and it took Apple months to release iOS 7.1 that addressed many of those issues. iOS 8.0 was much closer to fully baked than its predecessor on launch. Apples to Oranges, perhaps, but I see it as an improvement.

Going back to the Mac, I've yet to encounter most of the Yosemite bugs. In fact, Yosemite fixed many of the bugs I ran into with Mavericks. Both releases have their issues but is 10.10 worse than 10.9? Not in my experience.

If we're going to compare OS releases, let's level the playing field.

The debate shouldn't be whether Yosemite is less stable than Snow Leopard. The debate is whether 10.10.1 is less stable than 10.6.1. You can't compare the newly released Yosemite against Snow Leopard after it received 8 maintenance releases. If you want to avoid the early bugs, most should wait for 10.x.1 before you upgrade your Mac. I'd even suggest 10.x.2 for the conservative user.

Looking back on OS X releases ending in .1, I'd wager that Yosemite is the most stable since Snow Leopard. It's the first time in years that Finder isn't crashing for me at least once a week and I've yet to kernel panic on an iMac I use for work every day.

I simply don't accept that Apple's software is worse than it has been. It's easy to look back at the days of yore with fond memories and forget the bugs that existed in Panther and Leopard. After all, you're (probibly) not using 10 year old Macs today or fighting against its bugs.

Apple changed development schedules for iOS and OS X so they would have concurrent release dates. Among the many pro reasons, this allowed them to release features on both platforms concurrently, resulting in a win for end users and developers.

Is Apple's leadership aware of Marco's post and the growing complaints about Apple's software reliability? Yes.

Are they willing to stay quiet and ride out the storm? Time will tell.