Archive for iosdev

AppCode Review

As is well documented on Twitter, I’ve had my share of frustrating system locking beachball of death experiences with Xcode, so it should come as no surprise that I’ve been keeping a keen eye on JetBrains’ AppCode IDE for iOS and MacOS development.

Being a user of two of JetBrains’ other IDEs, Android Studio and RubyMine, I found the on-boarding experience for AppCode to be pretty familar and was able to get up and running in just a few minutes. Overall, the keyboard shortcuts are very similar to their other IDEs and there’s a lot of value in having a similar setup on multiple IDEs.

AppCode also includes many of the refactoring tools that you’ll be familar with if you use any of JetBrains’ other IDEs and has impressilvely just about been able to keep up with Swift 2.0. However, it’s pretty clear that the AppCode team’s fighting an uphill battle to keep up with the development of Swift and is still refining how the refactoring tools deal with the langauge — the AppCode team will likely have to devote continued effort to keeping up with Swift for the forseable future.

Unfortunately, keeping up with Apple’s development of Swift seems ot have come at a cost, the integrated UI designer. As explained here, the Designer has been made a plugin that can be added after you install the main AppCode package. It’s also worth noting that the plugin doesn’t work on all interface file types and was not useable at all for three out of the four test iOS projects that I used to evaluate the Designer. On the one project that it did work with, it was pretty disappointing and not at all an acceptable replacement for the tooling provided in Xcode for user interface design.

What I and I imagine the vast majority of iOS and MacOS developers want out of AppCode is for it to be what it originally was planned to be — a full Xcode replacement, but there’s a lot of ground to cover before it can qualify there. If JetBrains is serious about AppCode, then they’re going to need to improve the user interface designer to the point where 100% of an iOS or MacOS development project can be done in AppCode. Let me know what you think on Twitter.

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.