My long time friend, Alexander Carr, and I have launched a brand new podcast titled Tangential Soup. We plan on discussing plenty of topics including fitness, game development, life, work and more. If that sounds up your alley please head over to tangentialsoup.com and listen to the first episode!
At WWDC last year Apple told developers that they’d soon have access to analytics for their apps. On the eve of the 2015 conference the folks in Cupertino have finally made good on that promise, albeit in beta form.
While analytics for applications if far from a new concept, the options on Apple’s platforms have up until now all involved embedding third party libraries at build time and being willing to share your app’s data with the company providing that solution. For both of these reasons the team and I at Armchair Engineering decided not to pursue any of these alternatives, and instead wait and hope Apple would eventually deliver some means of gaining a greater insight into how one’s apps are performing.
Perhaps the best thing about the new analytics package is that not a single line of code is required to enable it, it just works. Upon launching the new dashboard you’ll be greeted with a colourful and graphic-rich overview of your app’s performance.
The data here goes well beyond the standard download and revenue numbers iTunes connect has always offered, providing figures relating to conversion, retention and engagement. The latter probably being the most immediately interesting to a small operation such as ours; its always nice seeing your software finding a place in people’s lives and isn’t simply being deleted moments after installation. Although, as we move forward the conversion information will go a long way to understanding where new customers are coming from and helping to identify areas that can be improved.
One drawback that is probably worth mentioning is that many of these important figures are collected only from devices running iOS 8 and from those users who have opted-in to share their data with app developers during the initial setup of their device (or potentially, although far less likely found and enabled this option in settings - Settings > Privacy > Diagnostics & Usage > Share With App Developers). The good news though is that despite this the number of users who have done this seems to be surprisingly good. For Temperature Converter (the app associated with the data in the screengrab above), Apple reports that in the last 30 days 22 % of users have in fact agreed to share their data. While this number isn’t quite as good for all of our apps, varying between 15 and 25 percent, there’s still plenty of data to be relevant and potentially very useful.
As we know the visual style of Apple's mobile OS changed significantly with the introduction of iOS 7, and like most developers the team and I at Armchair Engineering made a concerted effort to update our applications to reflect this new direction. Many of our apps make use of custom input views to provide a nicer numerical keyboard than the default offering, to refresh these we decided to make the number pad partially transparent, taking the lead of the standard system keyboard.
Both UITextField and UITextView have supported custom input views since iOS 3.2 and implementing them is really dead simple, even with a translucent background. That was until iOS 8 came along, which for whatever reason introduced a solid grey view underneath all custom input views and, as you can see from the screenshot below, completely ruined the semi-transparent effect we were going for.
The first solution we tried was to walk through the view hierarchy, find and alter the opacity of the offending view (UIKBInputBackdropView). While this approach does work, the keyboard is redrawn every time it appears and we often saw a short glimpse of grey each time before being able to hide that pesky backing view, which looked a little too sloppy for us to persist with long.
Both UITextField and UITextView also have an inputAccessoryView property, which is used to place an additional view atop of the keyboard to augment and provide additional functionality. We were already using this to provide a quick way for the user to jump back and forth between the text fields and for the clear all function (also visible in the image above). Unlike good ol' inputView this accessory view was never gifted a grey backdrop with iOS 8. As such the easiest solution turned out to be to just use this for the whole keyboard, and set an empty UIView of size zero as the inputView, bypassing it altogether.
Last week Apple seeded the first OS X 10.10.3 beta to developers, bringing with it the initial build of the much anticipated Photos application for Mac. Some digging around by a couple of particularly inquisitive devs, Jonathan Willing chief among them, stirred up excitement with the discovery of a hidden UXKit framework linked to and presumably used by the new Photos.app. This framework appears to bring much of iOS’s UIKit to the Mac; the API behind most user interfaces on Apple’s most popular platform.
To understand the interest garnered by this framework one must first understand the differences between UI code for the two operating systems. Today the equivalent of UIKit on OS X is AppKit, a nice but not exactly modern set of APIs, which in many places bares little resemblance to that of its younger brother. As Jason Snell of Six Colours puts it:
For a while, iOS developers have complained that the UIKit framework they use to develop apps isn’t available on the Mac, making it harder to apply the same tools and techniques and code they build for iOS to Mac apps.
As a developer of apps for both platforms I can attest to this, while making anything remotely custom for Mac is possible its just painful when compared to iOS. The effort required to set a custom resizable background image and a separate foreground image on a NSButton is just ridiculous, a task UIButton makes trivial. Something similar to UIKit for the Mac would be a huge upgrade in my opinion and I hope Apple is indeed looking to make this available to all developers, even if some feel that’s unlikely. Bring on WWDC 2015!
The latest episode of David Smith’s excellent and oftentimes inspirational podcast, Developing Perspective, tackles the question of whether the App Store may be nearing capacity. With well over a million applications just a tap away I can certainly see the thinking underpinning Underscore’s query. However, quantity is never a substitute for quality and my philosophy is that while everything may have already been done, it can always be done better.
If you share a similar view, you too may sometimes wonder how good products seem to go backwards even when given every opportunity to evolve into something much greater. When Apple acquired TestFlight earlier this year many just hoped the folk at Cupertino wouldn’t let it fade into the ether as has happened with some other services in the past. Few were completely optimistic about the news, at best like me some were hopeful that arguably the best beta app testing platform for iOS becoming more tightly integrated with everything else Apple offers developers would come with huge benefits.
In some respects the current incarnation of Testflight is far superior to its predecessor. For instance, adding new testers to a project can now be done with just an email address, a god send for anyone familiar with the painful process of obtaining a device’s UDID. Unfortunately Apple did what only Apple would do; require all beta builds go through App Store review prior to distribution to external testers. Try as I might I fail to see the logic in this. External testers are limited to 1,000, so any possible fears of dodgy software being distributed en masse surely aren’t founded. And beyond that the whole point of beta testing is to be able to quickly get the latest versions of something into people’s hands so they can provide feedback and assist you as you continue to iterate on it. Waiting five to goodness knows how many business days for a build to be approved makes the whole thing a non-starter!
I hope Apple rethinks this nonsensical setup as I’d love to see the back of UDIDs and just to be able to do everything in one place. For the time being though I’m still using and am very happy with HockeyApp, which incidentally was just bought by Microsoft. Let’s hope Redmond’s influence isn’t quite so disruptive.
Originally posted September 17, 2014
It would seem the reaction to Apple’s recent announcement concerning their entry into the wearables market has be mostly positive, which I did not predict while following the event.
We’ve already seen many wrist-worn devices come out from a multitude of manufactures over the last couple of years but with the possible exception of the recent Android Wear devices from Samsung, LG and most notably Motorola, these gadgets have fallen seriously short in so many areas that they have been the envy of only the most die-hard tech enthusiasts. The Moto 360 deserves special mention for being a rather sharp looking little device with a round LCD, quite novel even in 2014, but the question still remains: What value does strapping something to my arm, which I’ll have to remember to charge every day or two, provide over the phone I already have in my pocket?
So far I’m yet to be convinced, I never really had that I have to have that moment while watching the Apple’s keynote apart from maybe when they were pitching the fitness angle, but even then aside from recording my heart rate my phone can do all that. Jonny Ive has again done great work but for me the value proposition remains allusive. Perhaps once battery technology advances to the point where I can have a watch that lasts weeks not days and the price comes way down it’ll become a no-brainer, but I wonder how far away that day may be.
So I won’t be getting one right? Well no, I almost certainly will be, just like millions of others and that’s the point. Regardless of the current limitations this is a new platform, certainly something to get excited about and with the weight of Apple behind it there will be users and the chance for developers to carve out a new place for themselves. Looking at our current portfolio at Armchair Engineering it may be difficult to see what if any of our apps makes sense on a small screen but there are opportunities there. Of course this sort of hardware also opens up an abundance of new possibilities making it a compelling device to any developer looking to sink their teeth into watch kit and create something for this new wave of computing.
I’d still suggest most should hold off initially as the second generation will undoubtedly be a significant jump over what Apple previewed last week, but hey maybe you’ve just been dying to send your heartbeat to that certain someone.