Link: Android is a Dead End

I really want to write a far more detailed and in-depth article explaining why I think Android is a dead end, but I can’t yet fully articulate my thoughts or pinpoint why, exactly, I’ve felt like this for months now. All this doesn’t mean Google is going to get out of mobile operating systems, and it doesn’t even mean that the name “Android” is going away. All it means is that what we think of today as “Android” – a Linux kernel with libraries, the Android Runtime, and so on on top – has served its hackjob, we-need-to-compete purpose and is going to go away.

Android in its current form suffers from several key architectural problems – it’s not nearly as resource-efficient as, say, iOS, has consistent update problems, and despite hefty hardware, still suffers from the occasional performance problems, among other things – that Google clearly hasn’t been able to solve. It feels like Android is in limbo, waiting for something, as if Google is working on something else that will eventually succeed Android.

— Thom Holwerda,

Would anyone other than Google be able to effectively drive Android? No. Samsung and Amazon put all of their efforts into forks of Android for many reasons. With all of Google’s efforts into Fuchsia and Chromebooks I think Android’s darling status is far from assured.

Link: The Problem With Abandoned Apps

Marc Zeedar takes a look at the maturity of the App Store and finds it lacking. All of the issues identified are real problems and present grave risks to the App Store. Article:, “The Problem With Abandoned Apps”

The Fast App Wins the Race

The results come as no surprise; the slower your pages, the less pages your users will view. Given that most people have a threshold of time they’ll spend exploring your pages before heading elsewhere, every moment within this threshold is of vital importance. The less pages users view, the less chance your funnel has of accomplishing the user action you’re hoping to encourage.


Popular social networking apps are over 400 megs. With weekly releases, over one year you’ll download twenty gigs of data.

Since we launched Halide, the most unexpected compliment we’ve heard is about its size. At 11 megs, we’ll push less data in one year than a social network pushes in a single update. […]

Our advice doesn’t help the apps with the most bloat. Social networks make money from advertisers, and advertisers need detailed analytics for ad targeting.

Big apps have hundreds of developers, making up dozens of teams, each with independent quarterly goals. The faster you go, the more goals you land, the more likely your promotion.


I’m a proponent of the Halide approach to prevent cruft in apps. Distributing smaller apps has great customer cost savings. Having faster apps through smaller download sizes and faster operation drives commerce as shown in the article.

Business Cards

I’d like to share one side of my business cards. Perhaps too much effort went into these cards. If you get in contact I’d be glad to hear about your app project and how I can help make it a reality.

The idea for these cards is to convey familiarity and expertise with iOS and iPhone app development. Early on I realized it traditional text card would not stand out and that I could create cards from iOS screen shots.

The front of the card is an app screenshot with a tab bar, navigation view, and table view— every aspect of these cards was captured from an iPhone. The table has two sections which of contact information and services. Each row contains a piece of information on the left and on the right in emoji icon for that entry. I used a simple storyboard to make the front of the card.

The tools I used include:

  • Static table view inside a storyboard from an empty project
  • QuickTime iOS device movie capture
  • Zoomed-in display mode
  • Incorrect device clock, to make the reminder always show a due time of “Now”
  • Pixelmator for custom gradient backgrounds (custom backgrounds were easier to modify)
  • Pixelmator’s repair tool, to remove the date and the lock icon
  • Pixelmator for scaling and “stretching” the gradients
  • Imagemagick to create the gif (convert -delay 200 -size 648x1098 back[1-9]*.png -loop 0 business-cards.gif)

You’ll have to meet me in person to see the rest of the card!

iOS lock screen with reminder stating "call Joe P. about that app idea!"



Attack of the Clones

Every time Apple’s developer conference rolls around we get a smattering of changes to the App Store Review guidelines. This corpus of rules can be, in turns, opaque and explicit, and has caused a decent amount of consternation over the years for developers as they try to read into how Apple might interpret one rule or another.

I remember the crushing of apps like AppShopper and AppGratis, for instance, under the boot heel of rule 2.25, which forbid apps from “duplicating” the features of the App Store. AppShopper eventually returned, finding a way around the rule by adding social features — something which the App Store still largely lacks, by the way.

This year the big issue appears to surround rule 4.2.6, which states that “Apps created from a commercialized template or app generation service will be rejected.”

— Apple goes after clones and spam on the App Store, Matthew Panzarino, TechCrunch

Panzarino provides a good analysis of this new App Store rule. This reminds me of the earlier App Store leadership statement that “amateur hour is over”. An easy way to express this is that apps must provide value. 


While working on a side project for fun I had a need to query the Health app and retrieve workout samples from a given date range and of a given type.

The HealthKit APIs accept NSPredicate objects or you can use convenience functions that accept workout types or dates. To use both a date range and a workout type one should construct your own predicates and combine them with NSCompoundPredicate. This code gist (embedded below) shows a very simple use case for Swift 3.0.

How I Work

Hi, I’m Joe and I write iOS apps. There are many personalities in software development and you should know how I work before starting a project together.

I like to work with fixed weekly updates; meetings or calls that are at different days or times are chaotic but daily meetings are often too much. Collaboration is enjoyable and I prefer shoulder-to-shoulder interaction as opposed to infrequent or siloed communication. Projects ebb and flow between intense development and rapid testing/feedback which does change communication needs.

Version control through Git is vital and the absence of a repository is professional malfeasance. A well populated README is a happy project and can alleviate code documentation. I prefer code explanation rather than documentation; explaining why and how a knotty or obtuse function works rather than listing all the variable names and types. Project accessories (like set up or automation scripts) should be included in a repository and have explanatory documentation. Automated testing and tools like Snapshot (part of Fastlane) are excellent in reducing and preventing bugs.

I hope this helps you understand how I communicate and if you’d like to work with me please get in contact.