“When my first app became available in the App Store on June 10, I hoped to make about $100 from it. I priced it at $0.99, and figured at least a few people would be looking for a Bible verse app for their Apple Watch.
I quickly realized I wasn’t going to make my revenue goal when by early October the app had only sold a grand total of 14 copies. So, I made it free. Now it’s up to about 90 total downloads.”
When I launched my first app, Lucky Dip, in 2009, I had high hopes. Sales figures of the app dashed those hopes in no time. It went from 0.59p to free after about a month, and I incorporated iAd in 2010. Even now, after three years of being off sale, it still brings in some advertising revenue.
These days, my expectations are far more modest: I don’t want crashes, and as long as I learn something new, I’m relatively happy. The gold rush of years ago no longer exists.
“Patronage works. I may be taking a pay cut for a while, but it’s still very profitable for an individual. As long as I can keep the lights on and the virtual servers running, I’m making enough, and I’m not doing anything that anyone else can’t do.”
Patronage—making an app free and asking for on-going voluntary subscription payments—is a perfectly valid business model. In the podcast app space, where there are multiple third party apps competing not only against each other but with Apple’s free Podcasts app, business is cut-throat.
In order for patronage to work it requires a confluence of events that are very rare for most independent app developers: a significant and dedicated customer base, front and centre placement on the App Store, extensivemediacoverage, people willing to pay, and, to tie everything together, a quality product.
I don’t think Marco meant that patronage works in every scenario. If he did, it’s remarkably naive. In either case, it’s poor word choice.
Disclaimer: I bought Overcast 1, paid to be a patron on Overcast 2, and have bought various other podcast apps in the past, including Castro and Downcast.
I was genuinely excited by the iPad Pro. I spent an afternoon refreshing the Apple Store app until the much anticipated Buy button appeared. I ordered the 128Gb Wifi + Cell model, with keyboard, and then waited impatiently for delivery to my office.
After unpacking, clicking the iPad Pro into the keyboard, and completing all of the on-boarding screens, the home screen animates in. I couldn’t help but be impressed by the 12.9’ display. It’s pin sharp with an amazing range of colour. At this point I would have loved to have tested the Apple Pencil, but as Apple only manufactured about 15 of them, I wasn’t able to get one. I made a FaceTime call to my wife and then went back to work.
Upgrading from the iPad Air to iPad Pro meant that this was the first time I’d have Touch ID on an iPad. Unfortunately, I found it lacking: if you have an iPhone 6s or 6s Plus you’ll notice that Touch ID doesn’t unlock as quickly on the iPad Pro. I originally thought that this was because it had a bad scan of my fingerprint, however, it’s actually because the iPad Pro is outfitted with the first-generation Touch ID sensor from the iPhone 5s/6. It’s a minor disappointment, especially on a brand new flagship device.
I downloaded and watched the first episode of BBC’s The Hunt and Casino Royale. iPad Pro has undeniably louder and clearer sound that its smaller siblings, thanks to the four speaker setup. It’s a design that I hope trickles down to the Air.
With such a vast screen, board games have great potential on the iPad Pro. I played Ticket to Ride for a short while and the iPad Pro weight was immediately felt. It’s not so heavy that it’s unusable, but it’s certainly not usable as a handheld device for any great length of time.1 Indeed, due to the weight, the iPad Pro is not as good as either the iPad Air or the iPad Mini when it comes to reading books or browsing the internet for long sessions. (This doesn’t apply when the iPad Pro is resting on you, for example, in bed.)
I also found that using it while walking—a use-case that all other iPads excel in—was extremely difficult. Specifically, if you use a complex alphanumeric password and Touch ID doesn’t recognise your fingerprint, typing your password on the go is an almighty pain.
Finally, unlike the iPad Air and iPad Mini, the iPad Pro is problematic to use on public transport. On my daily commute I found that the iPad Pro was too big to use on a crowded underground as I was conscious of it going into the back of someone in a tight space.
Desktop Usage with the Smart Keyboard
The Smart Keyboard is an okay keyboard. The keys have a nice feel, good travel, and as a bonus (for a new parent) it’s splash proof. However, the laptop form factor of iPad Pro plus Smart Keyboard is an ergonomically poor design.
First, the iPad Pro is stuck in place with a static viewing angle. I found that comparing the iPad Pro to my Macbook—heck, even my iMac—with their variable viewing angles made the iPad Pro look compromised as a desktop device.
Second, using touch based navigation on a tablet in a desktop position is uncomfortable. I felt that I was physically having to do more work to get the iPad Pro to do what I wanted it to do, than I would otherwise have had to do with a traditional keyboard and trackpad combination.
The worst part of this is that I recall suffering these compromises before with the original iPad keyboard dock. Back then the iPad was docked in a static portrait position and you needed to use touch to navigate. I find it astounding that these compromises persist five years after the original keyboard dock was released.
Multitasking and Productivity
The iPad Pro supports two flavours of multitasking: Slide Over and Split View.
Slide Over I found to be the more useful of the two. It lets you slide an app into an iPhone sized layout on the right side of the screen. Browsing while reading your Twitter stream, or reading emails…all possible. I found that as I installed more apps the Slide Over app picker filled up to a level where I ended up scrolling for several seconds before I found the app I wanted. It’s a minor inconvenience of the current UI, but it’s low hanging fruit for Apple to fix.
Split View lets you drag (certain) apps into a 50-50 screen split with another app running. As a multitasking solution I found it to be restrictive. A screen of this size, and a device with this power, should allow for more than two apps to be running side by side. This is a fundamental problem with iOS: it’s an operating system designed for one-app-at-a-time usage. Multitasking feels like an added extra, a product of auto-layout, rather than a system-wide feature that was considered at the inception of iOS.
Similarly, the App Store and its restrictive rules will limit the productivity potential of the iPad Pro.
To give an example. The headline is that Microsoft Office is available for iOS, but that’s only part of the story. If I want to run some Visual Basic macros in Excel, I can’t do it on iOS. Not only is the functionality not there, it’s also not permitted:
“2.8 Apps that install or launch other executable code will be rejected”
App Store Review Guidelines
As an aside, and talking of code execution, I’d love to see Xcode Playgrounds on iPad Pro (even on iPad in general). It’d be a great way to get kids into coding.
A long time request from developers is that the App Store should allow for trial versions of apps, and I think it’s needed now more than ever. Pro apps with pro pricing, and a liberalisation of the App Store rules is the only way developers will put in the required effort to build more complex and ultimately more productive apps. Otherwise, I think the iPad Pro will remain nothing more than an iPad Plus.
The iPad Pro has fantastic hardware but no software that genuinely utilises it. At times it tries to be a handheld touch device, for which it is too big and too heavy for prolonged use. At other times, it tries to be a desktop device with a combination of a touch interface and a hardware keyboard, resulting in a mishmash of compromises that make it a physically inconvenient device to use. App Store rules artificially limit its productivity potential. It’s trying to be a jack of all trades and mastering none of them.
For the first time in 10 years of buying Apple devices, I am returning a product. Simply put, it doesn’t excel in any of the use-cases that I’d expect it to, and in many ways I feel as though it has regressed from the iPad Air.
Settings -> General -> Reset -> Erase All Content and Settings
The iPad Pro is comparable in weight to the original iPad. However, as it is a bigger device, I felt as though I was far more conscious of its balance in hand. ↩︎
The error handling model in Swift is easy to follow. For example, in the below code I am saving changes to the Core Data persistent store and if there is an error when saving a UIAlertController is displayed to the user:
When I was setting up this version of my website back in June, I decided that it needed to support HTTPS. I purchased a Thawte SSL 123 certificate through Namecheap, completed the certificate signing request formalities, uploaded the files to my server, and then configured nginx to serve the website through HTTPS (my config file is at the bottom of this post).
Around a month ago, I was alerted to Let’s Encrypt. In their own words, Let’s Encrypt is a free, automated, and open Certificate Authority. The fact that it was free was good, but what caught my eye was that it was automated. I immediately signed up to the limited beta and began testing. Below are the steps that I followed:
Logged on to my server, then:
git clone https://github.com/letsencrypt/letsencrypt
./letsencrypt-auto --agree-dev-preview --server \https://acme-v01.api.letsencrypt.org/directory certonly
Finally, I made changes to the nginx default config file, specifically to the ssl_certificate and ssl_certificate_key items to point to the new Let’s Encrypt files.
That’s it. All in, it took about five minutes and as you can see the site is fully trusted with no errors.
Let’s Encrypt goes into public beta in early December. If you want to add HTTPS to your site, I’d highly recommend using their certificates.
return 301 https://$server_name$request_uri;
# enable session resumption to improve https performance
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
# enables server-side protection from BEAST attacks
# disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS http://en.wikipedia.org/wiki/Secure_Sockets_Layer#SSL_3.0
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ciphers chosen for forward secrecy and compatibility
# config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
# to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";