awkwardhare

[awkwardhare]

Terminology: An App Story

In 2009, I was playing with ideas. I was an independent software consultant doing a mix of web and internal business software. I had been experimenting with iPhone apps for about a year. I had built and released one simple app.

The app itself did not do much, but shipping it gave me experience in the process and the confidence to know I could build something better for this growing platform.

I was doing well enough with my consulting business to let myself invest time in more experiments, with the hope that shifting my focus to building products could provide a more balanced and diverse profile for my business. Oh, and it was fun to build iPhone apps.

So I set out to build a truly unnecessary, niche app for writing short form poetry. An app that would launch with a resounding thud and quickly fade from obscurity.

While working on that app, I was looking for data sources to assist a writer in selecting words. I found WordNet, and started playing around with parsing and presenting its semantic reference in useful ways. While experimenting, I realized it could be the basis of a standalone product.

By now we've arrived in 2010. At approximately the same time this little light bulb flickered in my head, Steve Jobs was sitting awkwardly on a couch on the stage of the Moscone Center explaining the magical new device he held in his hand – the iPad.

I had the idea – build a standalone dictionary/thesaurus app. I had the inspiration – make it an example of what was possible on this exciting new device. So I set to work on what would become Terminology.

When it was launched in July, 2010, as an iPad only app, the iPad was only 3 months old. The iPad App Store was populated with mostly thrown together updates of iPhone apps which did not comprehend the new device or its new user interface opportunities. And, kids, like in the stories your grandparents tell, people were willing to pay for apps.

Terminology did well. It was featured. It made it to the Top 25 on the iPad charts. Phil Schiller even tweeted that Terminology was one of his favorite iPad apps. More importantly to me, it set me on the path I have been on since, creating and selling apps for Apple platforms. I built the iPhone version, then on to the next app, and so forth.

Fast forward to Summer, 2016. Reviewing my app portfolio, Terminology was languishing. Other than bug fixes, it saw its last significant update with the release of iOS 7 years earlier. It was still quite functional, and had a small but avid user base – but it was falling behind on iOS technologies. The development work that be required to modernize it showed little signs of being a profitable effort with its existing business model. Retooling it for a different model seemed liked a gamble at best.

Averaging a few of dollars a day in sales, I was close to removing it from the App Store and calling it a day.

Then something unexpected happened. Terminology was selected as a Starbuck Pick of the Week in October, 2016. Agreeing to this meant giving the app away, but I had little to lose, so I gave it a shot.

What followed surprised me. Not just the sheer number of downloads, but that quite a few of those downloads were "sticky". Daily and monthly active user numbers went up and stayed up. Retention numbers were very good.

When I built Terminology, iOS did not have a system dictionary. I wasn't sure there was still a market for a standalone app. But it seems there was...so I set to work modernizing the app and aligning its business model with the new App Store market realities.

This week I'm relaunching Terminology. Same great word reference that established it as a go-to tool for writers. Same great extensibility that distinguished it from the competition. Lots of cool new feature to set it apart from competition in the reference space (like a Share extension)...and a freemium business model that can improve its availability and sustainability.

Only time will tell if this was a good plan, but I'm encouraged that there are still opportunities to experiment and succeed in the App Store – even if the parameters have changed.

This release is the 40th App Store release build of Terminology. It's been a long, fun journey. I hope you’ll give Terminology a try. After all, it’s free.

[awkwardhare]

Purple is a Secondary Color

I went to high school from 1984 to 1986. Music was what I cared about more than anything else. I played my guitar for hours on end. I worked at the local record store. I sang in the choir. I play in the jazz band. My musical taste was opinionated.

I was not a goth, a punk, a new waver, or other narrowly focused genre fan – though I loved Bauhaus, Minor Threat and the Cure. Lou Reed was my spirit animal. Bob Dylan my guru. Hendrix my sage. 60s garage psychedelia, Grateful Dead-style jam bands, or even dulcet tones of Iron Maiden were fine by me.

The one thing I was not OK with was a huge mainstream pop artist. My distaste was fueled by misguided desire to have disdain for what was “in” with the popular kids. A desire reinforced by being the employee in charge of ordering 45 rpm singles at the record store…which made me the go-to guy to send the dregs of the shopping center record store customers to when they wanted to express their outrage that the latest Madonna single was sold out.

I don’t regret that these tendencies protected me from the Tsunami of Phil Collins/Genesis or Journey – but these were also the years of Purple Rain, and I could not separate the wheat from the chaff.

I don’t recall exactly when I sorted this out. Probably around the same time I was able to extract Willie Nelson from the morass of Country music. I matured. And Prince matured. His journey to divorce his art from the music industry is inspirational. He was one of the few that could walk away from what was expected of him.

And in his music I found everything synthesized into one. A musical enigma that could absorb every musical influence I cared about and not regurgitate it, but build on it and make something new.

<

p>Thank you, Prince, for the music. For the brilliant highs, the experiments that worked, and the for the ones I didn’t get, may never get, or will appreciate some years from now. You made me more human.

[awkwardhare]

Silent blue. Unperturbed by the migration of the clouds. The horizon cloaks a limit in the guise of infinity.

[awkwardhare]

#madewithpaper / fiftythree.com

[awkwardhare]

The kind gentleman spoke with restraint, Thinking his anger buried in the space between the words.

That space quivered and buckled, his intent betrayed.

[awkwardhare]

Music Picks for 2015

Not many words to go along, but these are some of the 2015 records I liked most...

Shinyribs - Okra Candy

Former Gourd Kevin Russell's Shinyribs is likely to remain as under-appreciated as The Gourds were over their 20 year career, but they are one of Austin's gems and bring it with a wide range of Americana, Soul, Blues and Gospel influences that never fail to be just plain fun.

Nathaniel Rateliff & the Night Sweats

Great, straight up Southern Soul with punchy horns. Can't go wrong.

Galactic - Into the Deep

New Orleans fun rolls on. Great musicians. Grooves don't some much deeper.

Brandi Carlisle - Firewatcher's Daughter

Houndmouth - Little Neon Limelight

Bonus TV Pick

Branching out from the music picks, I'm adding a bonus TV pick. By far my favorite show of 2015 was PBS's How We Got to Now. The show is a clear tribute to James Burke's great Connections series from the late 70s, but it's fresh and up-to-date. Each episode follows the historical development of a particular technology, tracing the cultural impact of the technology as well as the litany of unknown inventors and thinkers along the way. Episodes include glass, time keeping, clean water.

Highly recommended for any age. My 8 year old loves it as much as I do.

[awkwardhare]

Radio, Playlists, Podcasts & Connect

Dr. Drang's experience with Apple Music rang true for me:

What I’d really like to hear on Beats 1 is a resurrection of God’s Jukebox, Mark Lamarr’s late, lamented show on BBC Radio 2. It was everything Beats 1 is supposed to be: deep cuts from a highly opinionated “curator.” I really miss that show.

What I think he really longs for is that place where old radio show formats, streaming music and podcasts can meet – and we're not quite there yet.

Beats 1 radio is too limiting. It has its place and its value. Maybe for a particular cross-section of the generational demographic it will form a shared experience in the way MTV did in the 80s.

Connect is touted as a way for artists to reach their fans and build a closer social relationship, which is great but not really anything the savvy artists were not already doing on other social media platforms. It is also focused on actively performing, individual artists and does not solve the discovery problem or help me find great new catalog tracks.

Curated playlists are great, but are difficult to discover, lack context and insight and are deadends. If I find a great playlist digging through Apple Music, I want to know the curator, why those chose those songs and why they think they go together.

The perfect solution in my mind is to have a new kind of hybrid of podcasts and playlists. To this point, good music podcasts have not been possible due because you cannot simply including copyrighted tracks in your podcast and distribute it.

Apple Music would seem to have the opportunity to make this possible with the following:

Let anyone could have a Connect page – not just artists.

Individuals with Connect pages could share playlists to their Connect pages.

When creating a playlist for Connect, they could choose to include pre and post roll audio commentary attached to each track on the playlist.

When playing back a shared playlist, you could choose whether to include the audio commentary (much like Director's commentary on a DVD).

That's where podcasts and radio shows meet. Discover and follow curators (DJs?) on Connect, get on-demand radio shows from them. Then when you've added your favorite of their playlists to "My Music", you have the option to re-listen without the commentary you may not want to hear over and over.

You can already create something like this if you carefully dig through the streaming archives of some of the few remaining radio stations that allow self-programmed DJ shows, like WMNF in Tampa, KBOO in Portland. If you are into Americana, for example, my friend John Palmer's Wednesday Traffic Jam on WMNF is great. It's not easy to consume these archives, however, and audio quality is mixed.

Hopefully Apple Music will bring its focus on curation to the next level with something like this in the future. Imagine all the playlists. It's easy if you try.

[awkwardhare]

Contacts Framework Identifiers

Apple announced a new Contacts Framework at WWDC (2015). There's a great session on the framework as well reference documentation. It will be available in iOS 9 and OS X El Capitan in the Fall and promises to make it much easier to work with the system contacts datastore, which, to date has relied on a rather archaic C-style Address Book API which is painful to use.

I've experimented with the the Contacts Framework a bit. One thing that caught my attention was that the documentation specifically calls out that identifier properties for contact, group and other objects vended by the framework can be persisted between app launches.

This intrigued me, because it would be neat if, for example, my app Drafts could create actions that linked directly to a contact rather than having hard coded email/phone number information.

Universal identifiers seemed out of line with Apple's usual attention to privacy, so I thought I'd play around with how the identifiers work.

It appears the identifiers given are unique to the device, but not the app, and are changed if a contact is ever removed and restored to the device via any sort of sync process.

Assuming Device A and Device B, both synching contacts (via iCloud or other service), the follow statements appear to all be true:

App A will get the same identifier for the same contact as App B if both are running on Device A.

App A running on the Device A and App A running on Device B will get different identifiers for the same contact.

If a Contact is not removed from a device, it's identifier will remain the same for all apps requesting it, even if the apps are deleted and reinstalled.

If a Contact A is removed and re-synced to the device–because the sync account was removed and readded, etc.–it will get a new identifier.

This is the result of basic testing with iOS 9 beta 2, obviously some aspects of this could change before final versions ship.

Long story short, it would not be practical for Drafts to have an action that linked directly to a contact, because it would not be possible to sync that action across devices and still have it point to the same contact.

[awkwardhare]

Quick Take on iOS 9 URL Scheme Changes

[UPDATE #2: I have independent confirmation from several sources that these limitations are meant to only apply to "canOpenURL" and it is a bug that they are also effecting "openURL". There are still implications, and many apps will need some updates, but that's not so dramatic a change.]

[UPDATE: The more I think about this and get feedback from people on Twitter, the more I think these limitations on "openURL" have to be a bug. It would break too many things (like login workflows for Facebook/Dropbox). There are still significant side effects from the change to canOpenURL alone, but surmountable ones.]

During Session 703, "Privacy and Your App", at WWDC 2015 (video), Apple discussed changes impacting URL schemes on iOS 9. URLs are used extensively by some of my apps, so this piqued my interest. This post is a quick summary of how I understand the changes and their impact. Some of this could turn out to be wrong or change before iOS 9's final release, but I thought I'd get the discussion going.

What are URL schemes?

I will not attempt to define URL, but suffice to say URLs are the part and parcel of navigation on the Internet. You are likely quite familiar with web URLs like "http://apple.com". The first part of a URL, the part before the colon, is the URL scheme. The scheme is used to identify the type of service required to understand the URL, and most operating systems have a mechanism for applications to register that they are capable of opening URLs with certain URL schemes. The common example being the web browsers registering to open "http" and "https" URL schemes so that web links will open in the browser.

iOS has a system for registering URLs schemes as well. Some URL schemes, like "http" and "mailto" are reserved by Apple to point to their own Safari and Mail apps, but apps installed from the App Store can register to handle other arbitrary URL schemes.

Custom URL schemes like these are used by many apps for a variety of purposes. A common use is to deep link to a particular piece of content within an app – seen as an "Open in app" link from a web page.

Because of the limited available channels for apps to communicate with each other on iOS, URLs have been employed to expose functionality between apps as well. The iOS automation community has built a tremendous amount of functionality on top of URL schemes to allow apps to provide services, forward data to other apps, or simply launch other apps. If you use Drafts, Launch Center Pro, Workflow or many, many other apps, you are using and benefiting from URL schemes on iOS.

What is Apple Changing?

The key bits regarding changes to URL schemes in iOS 9 is the Privacy and Your Apps session, starting at around the 9 minute mark under the heading "App Detection".

There are two URL-related methods available to apps on iOS that are effected: canOpenURL and openURL. These are not new methods and the methods themselves are not changing. As you might expect from the names, "canOpenURL" returns a yes or no answer after checking if there is any apps installed on the device that know how to handle a given URL. "openURL" is used to actually launch the URL, which will typically leave the app and open the URL in another app.

Up until iOS 9, apps have been able to call these methods on any arbitrary URLs. Starting on iOS 9, apps will have to declare what URL schemes they would like to be able to check for and open in the configuration files of the app as it is submitted to Apple. This is essentially a whitelist that can only be changed or added to by submitting an update to Apple. It appears that certain common URLs handled by system apps, like "http", "https", do not need to be explicitly whitelisted.

I have tested these limits in Xcode 7 with the initial iOS 9 beta pre-release with the following results:

If you call the "canOpenURL" method on a URL that is not in your whitelist, it will return "NO", even if there is an app installed that has registered to handle this scheme. A "This app is not allowed to query for scheme xxx" syslog entry will appear.

If you call the "openURL" method on a URL that is not in your whitelist, it will fail silently. A "This app is not allowed to query for scheme xxx" syslog entry will appear.

It was not clear from the session if these limits apply to the "openURL" call, but in actual testing it appears that they do. It is possible (I hope) this is a bug.

Per the discussion in the session, these limits will be retroactively enforced on apps built and submitted to the store prior to iOS 9 by the system, which will build it's own whitelist of up to 50 URL schemes allowed for an app based on the actual calls made by the app. The session does not explicitly state a limit to the number of URL schemes that can be in the app's own whitelist, but I have to assume 50, or some other reasonable limit will be enforced – likely by a validator when submitting apps to Apple.

In practice, this means URLs are now something that can only be used to check for and open a small number of known outside apps. For example, the way Google uses x-callback-url based URL callbacks to create "Back" buttons to return to other apps from their iOS versions of Chrome and Maps could still continue to work between their own family of apps which they would likely whitelist, but would not be able to continue to be used by other arbitrary apps wishing to make that "Back" button appear in Chrome.

This will also practically kill any sort of launcher app, and prevent apps like Drafts and Workflow from accessing services in other apps, chaining URL callbacks and other complicated automation tasks.

Why is Apple Making this Change?

Apple is making this change for privacy reasons.

Although any app can register any arbitrary URL schemes and there is no guarantee that because the system returns "YES" from a canOpenURL call that a particular app is actually installed, registering unique URL schemes has become a de facto way to check if a certain app is installed on the system – and by scanning lists of "known" URL schemes with canOpenURL, certain apps (like Twitter's) have been abusing this loophole to scan your system for installed apps and used this information for whatever nefarious reasons – likely involving advertising.

Apple has been adding more secure and reliable ways to do many (but not all) of the things possible with URLs (Extensions, App Links, etc.). Long term these are important changes because it is true that there are implications to the uncontrolled use of URLs that may be exploited.

Possible Alternatives

I agree with Apple's concerns regarding the abuse of "canOpenURL", but if the current implementation is their intended solution, I believe it is too severe and will cause too much breakage and bad user experience for many users.

My hope is (as mentioned above) that these changes were only meant to apply to the "canOpenURL" method, and that it is a bug that they have also limited the functionality of the "openURL" call. I have filed a radar reporting this as a bug, if you are a developer and agree with my assessment please consider duplicating it (rdar://21320635 | openradar).

Even if that is the case, loss of the ability to call "canOpenURL" on arbitrary URLs will limit the user experience on many automation applications of URLs because an app has no way of testing if the URL can be opened successfully and will have to rely on the system to report errors. It might also be possible to allow it to continue to function for apps in a throttled fashion that would only allow a certain number of "canOpenURL" calls in a certain time period – thus hindering it's usefulness for scanning.

I have not fully thought out the ramifications of this change, and it was made public yesterday – but I wanted to get some thoughts out quickly to start a discussion and hope Apple is listening and willing to make good compromises that protect users and allow iOS to continue to be as powerful and flexible as possible.

[awkwardhare]

Release Notes Podcast

I was a guest on the Release Notes podcast this week talking about Apple Watch and it's impact on my business. Fun chat.

[awkwardhare]

Use the iTunes Affiliate Program. It’s Worth it.

If you are an app developer and not using the iTunes Affiliate Program, you need to drop everything and sign up. Period.

Using affiliate links is not going to buy you a new Ferrari, or send your kids to college, but as an indie it's an easy to use additional income stream that you should not overlook.

You may think affiliate links are somehow sleazy. Sometimes they are, but that is not true with the iTunes affiliate program. There are no weird URLs and redirects. To use the affiliate program links, you simply add an additional URL query parameter (&at=YOUR_AFFLIATE_TOKEN) to the normal iTunes links to any app, movie, music, or anything else on the iTunes/App Stores. Including your own apps.

I have a somewhat unique situation with my own apps, because a number of them specialize in integration with other apps, and I run a directory of actions which profiles integrations and uses affiliate links, but those links make up only a small portion of my affiliate income. Most of it is derived from direct links from my website to the App Store. My iTunes affliate program numbers for the last calendar year are as follows:

Clicks: 115,473

Units sold: 34,374

Revenue: $52,017.46 (App Store gross sales from my links)

Commissions: $3,641.26 (This is what I made!)

Conversions: 29.7%

The commissions are 7% on sales that result from your affliate traffic. In the case where a customer clicks on your link, to your app, from your website, and buys your app, that effectively means you have reduced Apple's cut from 30% to 23%.

The affliate links carry over to other purchases made by the user that followed your link as well. If they browse more and decide to buy a competing product, you also win.

If your app is free, and they follow your link, then buy something totally different within 24 hours, you win.

In addition to the commission revenue, you can gather useful analytics data from affiliate links if you include a campaign parameter (&ct=arbitrary_campaign_name) in your affiliate links. You can set this parameter to any value, and alter it when you use the links it different places. The affiliate portal breaks down your clicks/revenue/conversion data by these campaigns, so if you vary them for links from in your apps, from your website, from tweets, etc., you can get a good idea what links are most successful in converting customers.

This post is not intended to teach you how to use the affliate program detail, simply to encourage you to take advantage of this program which has no discernable downsides. If you are interested, here are some next steps:

iTunes Affliate Program Signup

Apple's Docs on using links

David Smith's Implementing Smart App Banners includes information on including affiliate tokens in banners.

[awkwardhare]

Open Letter to Apple Watch Early Adopters from a Developer

Dear Madam or Sir,

Congratulations on the purchase of your new Apple Watch. It looks lovely on your wrist. I feel the [model] with the [strap] was an excellent choice that fits your lifestyle and complements your wardrobe nicely.

I'm sure you are excited to play with the new watch. It's really a new and different device than you've owned before and it will likely take a few weeks, or even months, to get comfortable with what it can do for you and what role it will play in your life.

We developers are excited about our new watches, too. We also may take weeks or even months to make sense of what we can, should and should not do with our apps on the watch.

Many of us have worked with the tools Apple has provided to extend our iPhone apps onto Apple Watch. Many of us will ship watch apps right away, even though we don't have watches and might find in real world usage we need to make some changes.

Some of us will wait a while so we can learn what does and doesn't make sense for our apps on the watch.

Some of us will decide our apps don't make sense on the watch at all, or that the additional time and energy to create and support a watch app doesn't make good business sense for our apps.

Please enjoy the apps Apple has provided with the watch, and download lots of apps from third party developers who have added watch support to their apps.

If your favorite app doesn't have Apple Watch support, the best thing for you to do is contact the developer and politely let them know that you would like to see their app on your new watch. Include an explanation of what functionality of the app would benefit you on the watch and how you would use it. That will help us understand how the watch fits in your life and what we might be able to offer in our app that serves your needs best.

Try to stay focused on communicating the task you want to be able to acheive, not how we should implement it. We like to figure that stuff out ourselves.

Also, be aware that there are significant limitations to what we can do on the watch. We might like to make our watch app work without an iPhone nearby, make it play sounds, tap you, add a widget to the watch face, etc., but we do not (at least yet) have access to those features. Understand that if our apps are not as powerful and full featured as the ones Apple provides it may be because of these limitations.

If you do find apps that have added watch support that you find useful, we would love if you let people know about them. As an early adopter of the Apple Watch, you’ll be getting quite a few friends, family and complete strangers stopping you to ask about it over the next six months. Tell them about the apps you love and how you use them. Write a review in the App Store. This help us, the developers, and you the customers because it’s more likely we’ll be able to continue to improve and develop the apps you love if we are able to make a good business of it.

Thanks for listening, and get up and walk around now. Your Apple Watch is probably telling you the same thing about now.

Sincerely,

Indie App Developer.

[awkwardhare]

Regarding the App Store Revenue Split

Jeff Miller's Open Letter to Tim Cook is getting a lot of attention today. The gist of his proposal:

Therefore, please consider changing the App Store 70% / 30% revenue split to a tiered rate, where Apple takes less of the developer’s first revenues. For example, perhaps Apple could take nothing from the first $100K in annual revenue for a developer, and 30% after that. Or maybe Apple could take 10% from the first $100K, 20% from the next $100K, and 30% after that.

On the surface this makes sense for an indie developer, but I disagree. There are several purely problematic aspects to this proposal, like:

"Developer's Revenue" should be "App Revenue" – you'd have to do this on a per-app basis, I think, or the incentive to develop new apps for a previously successful developer is decreased.

It would incentivize questionable Developers to setup more and more separate Developer accounts to avoid hitting the revenue tiers.

If there was going to be any App Store revenue restructuring 1 I would prefer it address another issue...the freeloaders and gougers.

When Steve Jobs announced the App Store, the revenue split was pushed as a way to cover the costs of running the App Store. Free is free. Free being free is a good thing, mostly. If a developer wants to put a free utility in the store, great. I'm not entirely sure many of the free apps which get many thousands and millions of downloads to support an otherwise profitable business need to get subsidized by the revenue of other paid apps. I'm looking at you, Facebook, Yelp, ESPN, et al. This is a difficult one to manage, because it's in Apple and their customer's interest to have those apps in the store, but it seems there could be some point at which large volume "Free" apps get to chip in.

The more significant area where revenue split reform would make sense is consumable in-app purchases (IAPs). Consumable IAPs take many forms, but the vast majority of them are a questionable game advancement opportunities. I bet Apple's bottom line on App Store revenue would go up if they changed the split for Paid apps and one-time cost IAPs to 20%, and the split for consumable IAPs to 40%.

Economists say if you want to discourage a behavior, you tax it. This is a bit of a catch-22 because you might say increasing Apple's split on consumable IAPs incentivizes Apple to promote their use, but I don't think Apple sees the App Store as profit center so the net effect would be to shift the revenue burden off more reputable developers (indie or otherwise) providing the type of apps that make iOS devices useful in the way Apple likes to portray in their advertising, and onto the gougers in the App Store.

There's not going to be any App Store revenue restructuring. This is completely vacant speculation. ↩︎

[awkwardhare]

Why it's worth setting up Family Sharing (and not using it)

iOS 8's Family Sharing is a bit of a mess. David Sparks covered the reasons it's a mess, so I won't attempt to rehash that territory. Long story short, don't try to use it for your App Store login at the moment. Despite these issues, I have found a good reason to setup Family Sharing–then not use it.

I have three children. They each have their own iPad mini, and my two teenagers now have iPhones. They leave them in the strangest places. Under couches. On bookcases. Buried under Lego or dirty clothes.

They also often have the devices muted. The iPhones can't be used at school, so are muted all day and don't get un-muted at home. The iPads are often used with headphones plugged in, or the volume turned down to not annoy others in the house. Because of this, the old "FaceTime the device" to hear the ring and locate it doesn't work.

After iOS 8 came out, we setup Family Sharing and quickly reverted to a shared App Store login due to many of the issues. Because we linked the non-shared iCloud accounts, however, I can now see all the family devices in the Find my iPhone app on my device, without any login changes. And, unlike the simple location tracking provided by Find my Friends, the Find my iPhone service can be used to play a sound on the device to assist in locating it, even when the device is otherwise muted.

Pretty handy.

[awkwardhare]

In the late 80s and early 90s, I spent a lot of time experimenting with music production. I had a reasonably good amateur production setup for the era. Multi-track recording. SMTPE synced Voyetra for DOS midi sequencer with a Roland synth and drum machine.

Funny thing is, whenever I go back and listen to the stuff I wrote and recorded then, the ones that I like most are the ones where I just hit record on a cassette recorder and played.

This one is from set I did with a little handheld walkman with a condenser mic on it in 1991. Song is a bit melancholy but much better than I remembered.

Moral of this story? Don't over-complicate things.

[awkwardhare]

That Impractical Junk Heap

If the Episode VII teaser was a calculated play to trigger nostalgia, it did just that for me. I was 8 years old when the first Star Wars came out in 1977. I do not have many crystal clear memories from that age. I can only name three or four of the teachers I had in elementary school. I could only produce a very rough sketch of what my room at home looked like in that era. I can, however, tell you about the despair I felt when my family's opening weekend venture to see Star Wars at the White Flint Mall's five theater multiplex was derailed by my 102+ degree fever. We were there. We were in the line, damn it! I would have to wait for the next weekend before my mind would be blown wide open by the first movie that mattered to me. I can also tell you I saw Star Wars in its original theatrical run six times. One was Mike Almquist's birthday party. One was with a neighbor who hadn't seen it yet, and his excitement made it new for me again. It was a different time. There would be no DVD in three months. I saw Empire and Return of the Jedi on the their opening weekends, looking to relive those moments. Like most, I walked out of Episode I with a big "huh?" look on my face — so much so that I didn't even see II and III until I had kids who insisted on watching them. I don't know what Episode VII will turn out to be, and there will never be anything like the magic Star Wars was to my 8 year old eyes — but a sighting of that impractical junk heap that is the Millenium Falcon will always pull at my imagination like nothing else.

[awkwardhare]

iOS 8.1, iCloud & Random Hanging Issues

iOS 8.1 shipped with a serious bug affecting apps that use iCloud. If you have seen apps randomly hang, especially on launch, it's likely you are seeing the effects of this issue. Many apps use iCloud for a variety of data storage needs, so even apps that you were not aware were using iCloud may exhibit issues related to this bug.

UPDATE

A little bird tells me this issue has been addressed for iOS 8.1.1. If you are a developer who has experienced this issue, please test on the iOS 8.1.1 beta. Let me know if you see the issue return on the beta.

For Users

For the more technical explanation of the problem, read the bug report I filed with Apple. I will include some more developer notes below as well. For the non-techical, as part of the iCloud APIs, Apple provides a property an app can access to determine if iCloud is signed in and available for use to store data. Per the documentation, "Accessing the value of this property is relatively fast so you can check the value at launch time from your app’s main thread." Most apps which use iCloud check this property as part of their startup process because they need to make decisions about what data to present based on the availability of iCloud.

Starting with iOS 8.1 (and it's betas – at least b2), accessing this property started randomly hanging and not returning data to the app in a timely fashion. Sometimes it seems to not return at all, other times it takes so long to return that iOS's watchdog process decides the app waiting on the response has crashed and kills it. Thus the "crash on launch" problem.

Some of this information may be wrong, but based on the reports I've seen so far and troubleshooting I've done, here are some conclusions I've made - feel free to correct me if you have any more details:

The bug is not specific to any device. Any iOS device running iOS 8.1 can see the issue.

The bug may be specific to certain iCloud accounts. Not every one is seeing the problem, but it is widespread.

I believe the bug only occurs for iCloud accounts which have enabled iCloud Drive.

I do not think the issue is present on any release on OS X or any previous releases of iOS, only on iOS 8.1.

The problem is intermittent, even for effected accounts. Often a reboot of the device, or sign out-in to the iCloud account will resolve the problem, but only temporarily.

There is little developers can do to avoid this problem, so if you are a user seeing this issue, please be patient waiting on a fix and do not blame your friendly neighborhood app developer for this problem. Especially, do not blame them in an App Store review.

For Developers

As mentioned in my original rdar, the main issue is with [NSFileManager ubiquityIdentityToken], which should be safe to call on the main thread and is hanging.

I was able to temporarily workaround the worse of this issue in Drafts 4 by avoiding that property. I was able to do this because Drafts is not yet using iCloud Drive/Documents – only CloudKit. This bug does not exclusively occur in ubiquityIdentifyToken, however. Any method that inquires about iCloud's status can and will be hit as well. In Drafts, I'm relying on [CKContainer accountStatusWithCompletionHandler]. It seems less prone to the problem, but will also hang on affected accounts sometimes. At least it is async and doesn't hang the app at startup. For Drafts, when that method fails, I just temporarily disable my iCloud sync process and try again later. This workaround is of little use if you need to ubiquityIdentityToken, though.

If you are a developer, please dupe rdar://18702493 and try to get it as much attention inside Apple as possible so it can be resolved quickly.

Drafts Note

The workaround in Drafts currently does not fix this problem, just helps Drafts try to keep working while it's happening. In the current release of Drafts, sync will stop when this bug is encountered and if you go to Settings > iCloud you will be told iCloud is not available even though it seems you are signed in on the device.