most useless page on the internet stayed all green for the vast majority of the downtime.
There was naturally lots of speculation on exactly what the issue was. I think the most likely is something I saw Padraig Kennedy speculate on, that what people were seeing was a staging/test system (maybe for Analytics?). However, even if the data was not editable it does appear to be real data, with real unreleased apps/app versions and real revenue (we’re seeing revenue information for another developer’s apps in AppFigures - This is incorrect, revenue was not appearing in AppFigures. See my update below for an explanation). Whichever way you look at it, this was a serious bug/issue.
Now I’m being quite harsh here. I understand that these mistakes occasionally happen, and when you’re the size of Apple those mistakes become very public. There’s nothing that can be done about the fact that this occurred. What I have a problem with is the way it was handled. I know Apple don’t make public statements about this kind of event until they are certain what happened. But to bring the service back up without any kind of statement is simply not good enough. For it to be brought back online, you have to think that Apple were 100% certain that the issue was solved. Why are we sitting here more than 18 hours later with no idea what really happened to our data?
Update: I’ve been in contact with AppFigures and it does seem that revenue was not leaked into AppFigures. We had another iTunes Connect account that had been added to the AppFigures account and we had not noticed these apps before (it’s on a big AppFigures account and we were checking for strange data this morning specifically after last night’s events). My apologies for not investigating this part of the above thoroughly enough before writing about it. Dave
Dave Verwer
Contentful is the API-driven cloud CMS for mobile and web apps. Let marketing colleagues change content in your app without involving developers, or resubmitting the app. Contentful provides a powerful API and an easy to use iOS SDK and an Xcode plugin. We’ll send an amazing Emoji mask to the first 100 signups. Just send “iosdevweekly” + your address to [email protected]
This is an interesting one. At this week’s React JS conference, Facebook announced React Native which is a framework for writing iOS (and eventually Android) apps in JavaScript. We’ve heard this before right? Maybe not, details are a little thin on the ground at the moment but as I understand it there are no web views in sight on the device, everything is UIKit and they are also not pitching this as a write once, run everywhere solution. I’ll reserve judgement until I’ve seen it but tweets like this from Andy Matuschak are a good sign.
Update: Elvis Nuñez points out that there is already more information out about this, including code that I had missed.
This probably won’t come as a big surprise but this year’s instalment of the Stanford iOS course is focusing on Swift rather than Objective-C. If you’ve been putting off getting started with writing iOS apps or learning Swift, this might be a good point to get stuck in.
You are measuring your app’s performance using Instruments right? If you aren’t, or for anyone new to iOS development, David McGraw has a nice intro that covers three of the Instruments you should be using to measure performance and find problems in your apps.
Justin Spahr-Summers was inspired by an internal tool used at Facebook called Watchdog, originally mentioned in this article, and implemented his own version. The tool logs whenever the main thread is blocked over a given threshold. Looks like a useful debugging tool.
I’ve always tended to stay away from writing complex macros in my Objective-C code but I do know they are popular among many developers. Luckily the transition of these macros to Swift is pretty straightforward and Andrew Bancroft has some examples, the resulting code is so much cleaner too.
Speaking of Objective-C macros, Arthur Ariel Sabintsev’s project PrintlnMagic replicates the DLog macro in Swift. Once included in your project calling println() will also print the filename, function and line number. Looks very useful and could put a stop to println(“here”)… println(“here2”) while debugging. 😝
I bet Peter Steinberger knows more about UIKit than any other developer outside of Apple. In this article he walks through a regression in iOS 8 related to window rotation and provides a pretty clean work around that works on iOS 7 and 8.
Leandro Brasil imagines how several popular apps might take advantage of WatchKit. I think he’s gone slightly overboard in some cases with how much functionality they will have but it’s good to think about this stuff and the post might give you a bit of inspiration.
Fantastic post from the makers of Loose Leaf on how they really focused on the details of one specific tool in their app. You can tell even just from the GIFs here that it works great and was worth the effort.
Chris Eidhof with a great talk on building micro libraries in Swift.
Sam Davies has put a book together from his excellent iOS 8 Day by Day articles. There’s so much being written about Swift right now that these posts (and the book!) are a refreshing look at developing for iOS 8 (even though the code samples are in Swift, the posts concentrate on iOS rather than the language) and I’m very pleased to see them collected into a book.
Build innovative apps that make a difference and are used by millions.
Make reading easier and more beautiful on mobile devices!
Help create the next generation of project management tools.
Crazy but beautiful.