Creating Consumer Apps: What you need to know

Photo of man tapping smartphone by NordWood Themes on Unsplash

The overwhelming popularity of mobile apps has contributed to many success stories for a lot of companies, but that popularity has also caused a saturation of the market as many app developers try to cash in on the trend. Back in 2007, when Apple launched the iOS platform (it was called iPhone SDK at that time ), the world first became acquainted with the mobile app.  In those days, virtually any app that made it to Apple’s App Store had a decent chance of being perused and downloaded. Today, businesses creating a new app face a daunting amount of competition in the App Store as well as in Google Play and on other app marketplaces such as Amazon. If you’re thinking about developing an app, or are already invested in the process, here are a few considerations that might help your app stand out and become successful. (more…)

Swift Journal: Day One

Photo of Checkpoint Charlie, Friedrichstraße, Berlin, Deutschland by Etienne Girardet on Unsplash

Learning a language is sometimes confusing

I decided to jump right into Swift without doing any research into the writing done over the past month so that my opinions were not colored. My background is in the C/C++ and, lately, Objective-C of which I’ve become quite fond. I approached Swift with the hope that it would provide the same kind of  power I’ve found Obj-C/Cocoa to have, but with some modern newness brought in from other successful languages. It is too early, and the tools are too fresh, for me to draw conclusions on how useful it will be for production code other than that it does look promising.

TL;DR after the jump wherein I detail experiences with the Xcode playground and a small Swift based iPhone app.


  • It took only about a ten minute glance over the language docs to be able to port my C code to Swift
  • Explicit control of nil behavior such as when to require non-nil objects
  • Enums are first class types along with classes and structs
  • Property system like Objective-C’s with custom getters and setters
  • Aspect oriented features on the properties, didGet and didSet handlers
  • The beauty of every callable block being a closure: global functions, nested functions, class methods and traditional lambda style closures
  • Syntax shortcuts when they make sense like leaving off get for a readonly calculated property or return for one line closures


  • Tools: the playground, compiler, all are early versions and have problems; but we know that, and that’s why we will be shipping Obj-C apps for a while
  • The syntax is a step back from the terseness of Objective-C towards the explicitness of C++ (Python users are laughing right now; and yes Obj-C names are wordy, read that as “readable”, but the syntax mostly stays out of the way)
  • No headers; wade through the implementation to find the declarations you need (somehow Swift’s type declaration file avoids this)
  • I don’t think I like the declaration style var x: Int = 4 which reads like “assign something to SomeType” to me
  • It took some fumbling to figure out how to define outlets and actions in my first Cocoa Touch app (where are these language extensions documented?)


Digging Into the Objective-C Runtime

Photo of dog digging by jettef on Flickr

Greg Parker recently tweeted a link to fantastic site he created, An Illustrated History of objc_msgSend, that provides a trip through history of one of the likely most often called, but unheard of functions in iOS or OS X, objc_msgSend. The function dates back to NeXT and the origins of Mac OS and iOS. It’s interesting to see how it has evolved through the versions of the OS, the transitions between processor architectures, and how priorities in the algorithm have changed as hardware has. It was the underpinning of the Objective-C runtime back on those first PowerPC based Macs and still is today on the latest A7 based iOS devices. Incredible.

If you want to learn more about the Objective-C runtime it’s actually open source and is available from Apple’s open source site at objc4-555.1. To go along with the source Apple provides the Objective-C Runtime Programming Guide and Objective-C Runtime Reference. Definitely read through these and take the time to learn more about how the runtime and your modern Objective-C code are related.

Outside of Apple’s documentation, perhaps the best series of posts on the Objective-C runtime and how you can use it are by Mike Ash. Despite the fact that they date back to 2009 and 2010, they’re still very relevant today.

Finally, if you’re looking to do some hacking on the runtime itself, or experiment with patterns and practices from other languages check out libextobjc by Justin Spahr-Summers, one of the Mac developers at GitHub.

Thanks again to Greg Parker for the retrospective, his time spent hacking away on the runtime, and for the inspiration for this post!

Gate External Links in Kids’ Apps

Photo of wall and gate by Henning Kesselhut on Unsplash

Release after release, Apple raises the bar on its requirements for inclusion in its app store.  Sometimes these are welcome technical changes, like explicit user permission to access contacts.  Other times they feel more like hurdles for app developers and users to jump – or in this case, the appropriate metaphor is stepping through a flimsy backyard gate.

iOS 7 introduced a new requirement for kids apps:

24.3 Apps primarily intended for use by kids under 13 must get parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce

This requirement was probably inspired by the Children’s Online Privacy Protection Act (COPPA), which establishes rules related to collecting personal data from children.  Apple applies the requirement to interface elements like iTunes app store links and social sharing buttons.  However, the requirement is remarkably non-specific as to what constitutes a sufficiently sturdy parental gate.