Archive for iOS

A Farewell to Apps?

Ars Technica recently posted an article by Larry Seltzer that discusses the possibility of native mobile apps being marginalized by web-based solutions thanks to the increasing advancement of web standards on mobile. Normally, I’d ignore something like this — in most cases when you see the tech press post a headline that’s something akin to for will A kill B, you can rest assured that the content will be fairly overstated and that you’ve been taken by a click-bait title. For the most part, Seltzer does a good job of understanding some of the challenges faced when using web-based technologies to develop but overstates the desirability of having mobile websites replace apps while simultaneously overlooking obvious shortfall of a pure mobile-web only strategy: performance.

JavaScript interpreters have been getting better and better every year and most JITs (just in time compilers) are on track to annually provide “free” performance increases on most browsers for most common use cases. However, they’re not keeping up in terms of raw speed with optimized native code on specialized hardware — for instance, Swift code on Apple’s A8 processor in the iPhone 6S. Another thing to consider is that all of the code on a mobile website must be run through the browser’s JavaScript interpreter.

The idea that native apps aren’t necessarily right for all business needs is pretty obvious and I agree with the author up to that point, but most of the technical issues that he mentions have been addressed by hybrid apps. Hybrid apps using Cordova-based tool-kits such as Ionic address the most common performance issues seen with mobile sites and the lack of web-based APIs for some many hardware features by actually having native level tie-ins. Basically, they implement native API’s a layer below where the developer writes his app logic and expose a JavaScript version of the APIs for the developer to use. From a technical perspective, developers can write any hybrid plugin for any functionality released in a future version of Android or iOS, then access that functionality via JavaScript.

Mobile websites do have one advantage of packaged apps and that’s that they do not have to be distributed via the AppStore. This, however, is not a technical problem, but rather a policy one. Apple still opts to manually approve every single app submission and app update for their iOS store and that creates an artificial delay between developers completing a release and users being able to install it; in cases where the developer is fixing a major security issue, this can be devastating and needlessly exposes users to risk. Still, the advantages of being able to tie directly into device functionality and the performance increases gained make publishing apps via the AppStore mechanism or some enterprise deployment scheme the right choice for the vast majority of apps whether you are developing using native or HTML5 technologies.

iOS Needs to Go Pro

Apple did it! They launched another amazing, category defining product! Of course, I am referring to the iPad Pro. Coder Radio listeners will know that I have a fabulous gold model that I’m enthralled with. I truly believe that the Pro has the potential to become the primary computing device for the vast majority of business and home users. There’s just one tiny little problem with the device and my vision of iPad world domination: Apple.

Despite its name, the iPad Pro is more Pro and less iPad. Given the complexity of apps that need to be written to take full advantage of the Pro, the lumping it in with regular iPads puts an undue burden of backward compatibility on developers. In all likeliness Pro users are not going to be primarily the same types of users or at least using the device in the same way that regular iPad users user their tablets — the idea here is production on consumption. Apple should consider allowing developers to submit and publish iPad Pro specific apps that are not required to be backward compatibile to regular iPads.

Advanced productivity functionality is great but it would be even better if iOS didn’t limit what developers could do. Though iOS 9 has made some strides in terms of inter-app communications, there is still plenty of work to be done. I won’t go into a laundry list right now of API additions and changes, I’d like to see for the Pro but to start it involves greater inter-app communications and greater filesystem access.

iPad Pro apps are going to be expensive and time-consuming to develop. That means that developers are going to be under even more pressure to monetize their apps. Up to this point, the story of App Store pricing has been depressing to say the least. Apple’s been unwilling to work with developers on things that are very common in productivity oriented software such as upgrade pricing and trials. The reality is that many developers will not be able to afford to take full advantage of the Pro unless they can find an effective and predictible way to gain repeated revenue from their customers.

All in all, the iPad Pro is the best device so far to finally achieve the goal of widespread tablet computing in the productivity market, but there are some policy and API limitations that Apple will need to consider in order for the device to reach its full potential. Let me know what you think on Twitter.

The King’s Mores

The recent tragedy in South Carolina has brought questions of the Confederate flag being used on government buildings and other placaes that it might be offensive. Personally, I agree with the critics that it was wildly inappropriate for the US flag to be flown at half mast out of respect for the lives lost while the Confederate one was not lowered. In response to the tragedy, a number of retailers have decide to stop selling memorobilia with the flag on it and the flags themseleves. One unlikely follower in this trend was Apple with their App Store.

Apple has decided to begin enforcing rule 19.1: “Apps containing references or commentary about a religious, cultural or ethnic group that are defamatory, offensive, mean-spirited or likely to expose the targeted group to harm or violence will be rejected”. Basically, they are asserting that the Confederate flag is inherently damaging. The issue is that many of the apps in question are games that focus on the historical aspects of the Civil War. I persnally find this to be a gross over-application of that rule but even if you agree with teh decision, there is a wider issue at play that shoud be of concerned to every developer working on Apple’s platfoms.

Apple is no longer shy about using its absolute power over the App Store to enforce what might be considered its own preferences / world view. This is well beyond just protecting users from poorly coded apps or security flaws in third-party software. Apple is now enforcing their tastes and mores on every iOS user and (more frightenly) every iOS developer.

It’s been a long time coming but I think this is the last straw for me in terms of control from Apple. I just can’t justify having so much of my life and livelyhood be based on a platform whose owner has no issue with enforces their mores on its users and developer community.

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

WWDC 2014 Predictions

WWDC 2014

Well, it is that time of year again – when the tech space goes crazy with Apple fever and starts to have dancing iTVs and iWatches in their heads. From the Apple developer perspective, this is (like the WWDC of 2012) being preceded by increasing frustrations from the community regarding Apple’s tools but more their practices – these complaints have been grumbling under the surface and indeed I’ve been at the forefront of sounding the alarm, but some fights have already been lost and if history is any indicator the prominent Apple devs will be placated by pretty much whatever they get on Monday. Still, to be fair, if Apple could address a few core areas of developer pain, then there would be legitimate cause to celebrate.

Contracts / Intents: Windows Phone and Android both have viable solutions to interapp communication that work very well for the developer communities on those platforms, the platform vendors, and of course the end user. iOS, however, has no real solution to this problem; I don’t consider and a reasonable person would probably agree that the current URL schemes tricks are all just really sloppy hacks that should never be shipped and no sane developer would use them by choice if there were a better alternative. There is no technical reason that this can’t be done and at this point Apple’s stubbornness is doing a huge disservice to the developer community and the end user.

App Test Distribution: One of the most annoying aspects of being an Apple developer is that whenever a customer or even a teammate gets a new iOS device, we have to go through the whole rigmarole of getting the devices UUID, adding the UUID to our developer portal, regenerating a provisioning profile, and making making a whole new binary just to get that one new device into the testing pool. This is absurd. Apple for good reasons wants to limit how apps are distributed outside of the App Store but at this point, there system is too much of an inconvenience to developers (a group I strongly feel is important to their long-term success) to be tolerated one day longer. There is some hope – a few months ago Apple purchased Testflight and that suggests that they intend to streamline the test distribution system.

Mac Mini Refresh: I’ve been careful not to put oo many consumer / new product requests in these sort of posts but I am willing to make an exception for the Mac Mini. Though the mini is probably the least sexy device that Apple sells, it is extremely important for the developer community at large, as a ton of little shops are almost 100% Mac Mini shops. At this point, it is pretty hard to justify the purchase of a Mini given how old the tech in the device is and the somewhat poor value proposition – at least compared with the iMac or an equivalent Windows PC.

That’s it. I don’t think these items are too crazy but am not so sure that we are going see anything of significance in any of these areas. My guess is that we will see nothing the way of interapp communication, a half step toward an easier test distribution, and little more than a spec bump or price drop on the Mini.

If you want to troll me when I inevitably proven wrong on Monday, then please follow me on Twitter.

Going Mobile: Byword

This is the first entry into Going Mobile my series of reviews on mobile productivity software – I am defining productivity software as any software I use to get work done. For this first entry we have Byword for iPad, a great markdown editor for iPad (and actually iPhone too). It’s fitting that the first pick be a markdown editor, since the majority of this website has been written in markdown for some time; in fact, this post post has been drafted in the app on my iPad Mini.

Byword doesn’t strain itself to be the best looking iOS app on the market; in fact, it focuses more on function than form, however, it is still a pretty good looking app and leans very heavily toward the iOS 7 design paradigm.

What puts Byword ahead of the pack of mobile markdown editors is its integrated posting to Word Press and a number of other blogging platforms. This might seems like an unnecessary convenience but the fact is that effective blogging from a mobile device requires that the process be as frictionless as possible. A close second for my favorite feature in the app, is dark mode. Given iOS 7’s relative hostility toward nighttime use around a sleeping partner or spouse, it is refreshing to see third party developers taking the time to add dark modes and other quality of life features.

The app costs $4.99 currently and to unlock some of the advanced publishing capabilities, you have to purchase a $4.99 “premium” in app purchase. This is my only issue with the app – the app feels pretty incomplete without the in app purchase. That’s not to suggest that the app isn’t well worth it’s true cost of $10, but rather that this pricing scheme feels a little deceptive and in my mind brings down the (for lack of a better term) “class” of what is otherwise a very high-end experience. I’d gladly pay $10 for the app outright but understand that I’m in a fast shrinking minority; the reality is that thine pricing scheme probably was decided upon due to the unfortunate economics of the app economy.

If you’re in the market for a mobile markdown editor and are an iOS user, then I strongly recommend that you check Byword out. If you have any comments or app suggestions, please share them with me on Twitter.

Pallet Town: Intro to AFHTTPClient Part 1

Pallet TownWelcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

This week we are going to take a look at getting some simple networking done with the new hotness in iOS networking frameworks: AFNetworking. To be specific we are going to focus on one of its more important classes: AFHTTPClient Now there are is a little bit of a prerequisite here, we are going to go ahead and assume that you have already added AFNetworking to your iOS project and we are also going to assume that we are going to use ARC.

For starters, let’s take a look at how we instantiate the AFHTTPClient:

Now that we have our client, let’s say we want to make a simple RESTFul GET call; this sample builds a bit on our Pokemon themed ASP.Net MVC web app from the last installment of Pallet Town. Ideally, this call would just get all the Pokemon available on the API; this of course assumes you followed the normal MVC patterns in your routing on the API. Here’s the code:

- (void)getAllPokemon
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);

That was fun but let’s make things a little more complicated. Let’s say you want to pull a particular Pokemon via its Id. That’s still a GET request but takes a parameter like so:

- (void)getPokemonById:(NSNumber *)pokemonId
	NSDictionary* parameters = @{@"Id" : pokemonId}
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:parameters success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);

Getting Pokemon from the server is a lot of fun, but you know in the age of Minecraft, I like to  be a little more creative than just working with the set number of Pokemon that Nintendo provides. Tune in for our next installment to see how to POST my very own legendary Pokemon to the server!

Programming Pitfalls: iOS Simulator and Audio Codecs

PitfallThere are some bugs that you fix and brag about to your friends afterward, then there are the ones that are just plain embarrassing. Unfortunately, I’m writing about one of the latter today rather than the former.  You see this pitfall, though no more or less annoying than the others I cover in this series, is made all the more worse by the fact that I should have known better. If you’ve ever listened to an episode of Coder Radio in which I mention the iOS Simulator, then you know that I always warn developers to never trust it; the reason for this is that your code isn’t really running on iOS but rather a pseudo-OS X platform. Never ever trust the simulator. Ever.

Taking a step back, let’s look at the issue. I have a number of audio files and they all play just fine on the iOS Simulator, but my beta testers are reporting that they can’t hear any audio files at all on their devices. This is odd to say the least. I scoured my AVAudio implementation looking for the most obscure of bugs but still found nothing. The good news, using “good” very loosely, is that I was able to delete the app and reproduce the bug myself.

After a few hours of pouring over LLDB and various Test Flight logs, I found that everything looked fine: the audio URLs (the audio is coming from a server) all looked fine, there didn’t appear to be any NSZombie related issues, and the audio files themselves seemed fine.  I was totally lost.

Then I remembered something based on an offhand comment I found on a StackOverflow post — the simulator uses OS X’s audio subsystems which differ from iOS’s. In particular, OS X has access to a few more audio codecs than iOS. As it turns out, the API I  was interacting with has different calls that request the audio in different formats. I changed the call to request the MP3 formatted files and was good to go. Facepalm.

I hope you’ve enjoyed taking a look at another programming pitfall and please do leave any comments on Google+ or Twitter. Also, please keep in mind that I am always available for consulting projects.

UILocalNotification 100

Tomato SoupThere are a lot of cases where you will want to notify your user of some event of reminder without actually setting a formal alarm in their Alarm app. The standard solution most developers seem to take in these situations is to setup something like Urban Airship and fire off a push notification – this costly and shares the user’s data for no reason. Using
iOS’s UILocalNotification, you can pop a push-like notification without worrying about the hassle and potential cost of a push service and without sending any user data over the air. Checkout how easy it is to fire off a simple notification from this simple from my newly released Pomodoro timer Tomato Soup:

- (void)createNotificationForPomo:(TSPomodoro *)pomo
	UILocalNotification* notification = [[UILocalNotification alloc] init];
	notification.fireDate = pomo.fireDate;
	notification.alertBody = [NSString stringWithFormat:@"Nice work! Pomodoro: %@ is complete!", pomo.title];
	[[UIApplication sharedApplication] scheduleLocalNotification:notification];

// Now let's remove all notifications
- (void)removeNotifications
	[[UIApplication sharedApplication] cancelAllLocalNotifications];

Notifications like the one created above will still fire if the app is in the background, however, if you don’t want them to fire if the app is active, you will have to deactivate them on willResumeActive.I hope this helps you and that you reconsider how often you send user data over the air and use UILocalNotification as a simple alternative to push when appropriate.

Comments? Questions? Drop me a line on, Google+, or Twitter. Also, pickup Code Journal.

No, The Market is not Fine

There has been a lot of discussion recently in the iOS community regarding the so called “health” of the paid application market. My feelings on whether it is better to pay for the software you use to ensure that you are the developer’s main customer are well documented both on this site and Coder Radio, but, for new readers, I am an advocate of paying (and charging) for software. The most recent developer to throw his hat into this debate has been Marco Arment – the famous developer of Instapaper and The Magazine. Marco is a great developer and someone whose work I respect. His post is well thought out and reasonable – up until the last line where he states: “The bar is higher, but the market is fine”. Before diving into how someone as euredite as Arment could be so mistaken, let’s first define what it means when we say the bar is higher – apps now require a “better user experience” and a good deal of marketing to even be noticed by a reasonable number of users.

Yes, I know Apple has changed the world! Users now demand simple and elegant experiences. Isn’t that great? Well, no if you’re a developer, that’s terrible. That’s terrible, because, as a developer, you likely do not possess the design skills or experience to properly design an app of design caliber that a professional designer would. Like developers, designers do not work for free and a gifted designer who has been working in the field for any length of time command and handsome hourly rate. That means that to hit the required level of design, developers need to invest a good deal of capital in it.

Let’s say that you’ve got your design down and you’ve come to terms with your newly shrunken bank account – my condolences on that by the way. What now? Do you just passively wait for users to download your app? Perhaps you pray for users? Do a rain dance? Sadly, there is no evidence to suggest that any of the preceding will actually help your app become successful. Like any product (and yes your app is a product, not some work of self-expression), your app needs to be marketed. There are a lot of ways of to market it an app, though few of them are effective, but none of them is free unless you are a known quantity (like Arment) or able to convince one to push your app. That means you will need even more capital to get advertising for your app.

Like Arment, I agree that the bar is higher for apps than it was just a few years ago, but I contend that the bar being higher is a problem for the average independent developer. Many of these developers simply do not have the capital required to hire a decent designer and effectively market an app. So, if Arment seems to agree that the bar is higher, then how could he be so blind to the issues that poses for small independent developers? The answer is surprisingly simple: Arment is something of a celebrity in the Apple developer world. That means he doesn’t need to spend the capitol that others would to market his apps; In fact, his name and connections do that for him. In short, the bar is higher for all of us, but it is only half as high for Arment.