Let me add my voice to the chorus of those calling on Apple to refocus on software quality. Today’s surprise was that Xcode now breaks IPA packaging in the silliest way possible. Sure, it’s a quick work-around to unzip, repair, and re-zip an IPA, but, please, stop the regression. I’m at the point that I wince at every new (frequent) fix update. The rush to innovate is great, but let’s not do it at the expense of “It Just Works.”
After several runs of building native mobile apps for Android and iOS, I’m again using cross-platform (hybrid) solutions for those apps that don’t need heavy native capabilities. Mobile Enterprise App Platforms (MEAPs) based on Cordova are common, and a good place to start for corp-rat work.
IBM’s MEAP is Worklight (now called the MobileFirst Platform), and I’ve been running it through the paces. The Eclipse-based Studio is a free download from the Eclipse Marketplace, the online tutorials are quick, and the documentation is complete.
The suite includes libraries and server apps for app management and updates, analytics, authentication, push notifications, and other “back end” responsibilities. It takes awhile to learn how to correctly package apps and then production-deploy everything, but I got by with help from the doc and StackOverflow.
Worklight is a mature product that’s continually being improved. And with IBM’s backing and focus, it’s a good choice for all your MEAPing.
iOS 8‘s broader camera privacy enforcement has caught many photo apps off guard. For too long, apps have just grabbed a UIImagePickerController and hoped for the best. After all, if isSourceTypeAvailable: or isCameraDeviceAvailable: answers YES, what could possibly go wrong?
Well, a lot. Now, if the user dismisses the first “Would Like to Access the Camera” prompt, bad things happen until the user changes the camera privacy settings. Without access, various apps (including my own) running under the iOS 8 betas have responded with black capture screens, crashes, and other ugliness.
The fix, of course, is to check further for access and gracefully handle denials: disable camera buttons and display a message. Here’s one way to check:
AVAuthorizationStatus authStatus = [AVCaptureDevice authorizationStatusForMediaType:AVMediaTypeVideo];
AVCaptureDevice *cameraDevice = [AVCaptureDevice defaultDeviceWithMediaType:AVMediaTypeVideo]; AVCaptureDeviceInput *deviceInput = [AVCaptureDeviceInput deviceInputWithDevice:cameraDevice error:&error];
…will give a more helpful error message in the NSError’s localizedFailureReason, such as “This app is not authorized to use the Back Camera.”
Who knows; maybe we’ll start getting failure reasons of “excessive selfies.” We can hope.
On your iPad, iPhone or iPod touch, navigate to Settings > General > International > Language and change to a different language… The device will go through a language switch/reset process, and your AirPlay icon should be restored.
Next navigate back to Settings > General > International > Language (translated into the new language, of course) and switch back to your original language.
Change languages: love it! Fortunately, I remembered enough high school French to try it, but it seemed silly and didn’t work. But since it has worked for many others, it gets my vote for the most interesting work-around ever.
Like others before it, this week’s final release of iOS 7.1 brought the rush to grab the latest and greatest. Time to upgrade Xcode (5.1) and the SDK (7.1). Time to load the final iOS 7.1 on devices. Time to repackage and test.
Also like recent updates, this one carried an unwelcome surprise: for over-the-air (OTA) distribution, the plist must now be served over https with a valid (and CA-signed) SSL certificate. I discovered this one the hard way, when ad-hoc OTA installs of my apps failed with “Cannot install applications because the certificate for … is not valid.” This change was in the 7.1 betas, but I didn’t use OTA distribution for betas.
While I’m sure Apple meant well, this change has real impacts on those of us in the real world who use test servers for deployment, and yet don’t want the security risks that come with proliferating SSL certs. Fortunately, the work-around is easy: serve the plist (and only the plist) via SSL and serve the link and IPA over vanilla http.
Now that the media frenzy over Apple’s SSL (goto fail) MitM vulnerability has calmed and our iPhones and Macs have been updated, folks are starting to reflect. That’s a good thing. Among other things, this event has pushed issues of code quality, review, testing, patching/updates, version blocking and user notification up the management chain to, hopefully, get more focus and funding.
This had something for everyone and the net is now flooded with commentary on it. I’m certainly not going to repeat that, but consider:
- Some static analyzers (like Coverity and clang with -Wunreachable-code) would have caught this.
- Peer code review likely would have caught this.
- The bug was in the open source community for anyone to find.
- Vendors everywhere were asking how they could help notify their users and ensure they upgrade.
This one-liner joins the ranks of the most apt and pithy software bugs. It’s right up there with the misplaced break that broke the AT&T network on my 25th birthday. BTW, if your birthday call to me didn’t get through that day, there’s still time; call or message me. But please upgrade your iPhone first.
By managing two different teams at the Apple developer site, I’ve been able to compare iOS developer programs over time. The $99 individual and company programs are an OK first step, but you get what you pay for. With these programs, ad-hoc (pre-store) distributions are limited to 100 devices, each of which must be registered. And every new device registration requires updating provisioning profiles, refreshing, and repackaging. This also makes testing at cloud services like DeviceAnywhere a major hassle.
With the $299 enterprise program, you can get that magical ProvisionsAllDevices in your embedded.mobileprovision and get out of the device registration business. Unless you’re only distributing internally to a very small team, the $200 shakedown is well worth paying for.
Of course, when it’s time to submit to the store, you must use the non-enterprise membership, so that $99 company membership isn’t wasted.
Since the advent of NSLocalizedString, iOS localization practices haven’t changed much. But the new storyboards are easier to translate, particularly if you enable internationalization from the outset. To do this in Xcode 5:
- From the project settings (Info page), check Use base internationalization.
- For each storyboard, go to the File Inspector (utilities pane), enable Localization, and check at least Base and English. This will extract strings files that others can translate or customize.
- Un-install and then re-install the app from target simulators or devices.
After initial setup, adding languages and dropping in strings files is easy, and quicker than ibtool-importing strings into individual xibs.
Distributing in-progress iOS apps is tedious enough: setting up signing certs, creating provisioning profiles, adding device IDs, etc. I wanted at least the end-user install step to be friendlier than syncing with iTunes and remembering the .mobileprovision file. That is, I wanted to provide the same simple install for my iOS apps as I do for Android apps, with a web page that folks can visit from their phone browser and simply click a link to download and install.
Fortunately, I came across the itms-services protocol: Apple’s solution for wireless app installs. All it takes is the distribution IPA (with embedded mobileprovision file), plist, and a web page with the link. It’s not widely known, but there are a couple of good tutorials on the web, such as Apple’s instructions and Aaron Perecki’s walkthrough. No more tangles, no more wires!