Interminable dross
Woodstock ’99: Rage Against the Latrine
I remember this gross event when it happened. The way Woodstock transformed from a counter-culture event in the 60s into a mega-corporate event full of bros and violence set to the tune of shitty music encapsulates my mindset in high school perfectly: an awful mainstream culture that would sooner or later appropriate everything that was authentic and good and transform it into something deeply awful.
More statistics backing up lots of anecdotal evidence that the it’s a tough road for indie developers trying to make a living building mobile apps:
The report’s authors detail the specifics around the trend where a tiny fraction of developers – actually, it’s 1.6% to be exact – generate most of the app store revenue. Slyly referencing the “disappearing middle class of app developers,” the report’s analysis groups the estimated 2.9 million mobile app developers worldwide into a handful of different categories for easy reference: the “have-nothings,” the “poverty-stricken,” the “strugglers,” and the “haves.”
This is an interesting report, but shouldn’t be surprising to anyone who’s been paying attention. The App Store is so full of bad and mediocre apps anyway that it’s hardly surprising that so many do so poorly financially. Even if discoverability was a perfectly solved problem for them, they would never gain any real traction.
However, over the years as I’ve met enough developers of various successful apps – apps that have been featured in mainstream press, that have won Apple Design Awards, that have gotten promoted on the App Store – I’ve learned that even for extremely well executed apps, the number that have managed to actually build a sustainable business on that model is small.
The App Store more closely resembles other hit-driven media like music or movies: there are only so many Lady Gagas in this world. The huge majority are struggling garage bands lucky to book gigs at the local bar.
Error Handling in Swift: Might and Magic
Alexandros Salazar puts together an interesting technique for greatly simplifying error propogation through multiple layers of an app. As he summarizes:
The need for error handling during computations is abstracted away. All I need to do is specify what computations I want to apply, and
mapwill take care of propagating any errors.
This approach has the potential to remove a ton of boilerplate from the typical data flow of an application. As Alexandros summarizes, the flow of a typical app starts with retrieving data from an endpoint, then parses it into a JSON object, builds up model objects from that JSON, and gets that data on the screen. Each operation usually includes its own level of error handling. That error handling is almost always just propogation of the error from one layer to the next. Alexandros’s technique can simplify that flow such that at each level, the code is only concerned with handling the success case. The error case is automatically and transparently propogated to the next level. The error must eventually be handled of course, but that can happen only at the top level where the error needs to impact the UI. It cuts out all the code duplication of error propogation typically included.
Eliminating code, especially meaningless boilerplate code, is one of the most fundamental benefits any programming language can bring. Every line of code is somewhere a bug might be hiding. Objective-C requires a ton of code to do even very simple things. Techniques in Swift like this that hold the potential of eliminating huge swaths of useless code is extremely exciting.
