My Apple Smartphone is Kinda Dumb

The iPhone is still considered, by most, to be the gold-standard in smartphone usability.  It has been around for 12+ years and my family has owned 4 different models, the latest being the iPhone 8.  I must concede that, aesthetically at least, the device continues to "wow".

However, when it comes to content management (file management, data synchronization and backup), I regard its capabilities as quite primitive, leading me to question how smart we should actually consider the device.  I will discuss specific shortcomings later, but I first want to speculate on why this apparent blind-spot from a company usually so visionary.  I hope you recognize the interdependent nature of these observations:

1. An unnecessarily tight coupling with Apple's own iTunes and iCloud software, each of which has been criticized for its own usability issues.  
2. Apple does not appear to have seriously invested in iPhone file management, data synchronization and back-up strategies beyond its own iCloud service.  This means, effectively, that the company is up-selling its customers additional iCloud storage as the "free tier quota" is quickly consumed. 
3. Since the roll-out of the original iPhone, Apple's primary focus appears to have been on consumer-oriented features such as increased camera/photo resolution, video recording, voice control (Siri), touch ID and improved battery life.  Each of these enhancements play well in advertising campaigns as they are relatively easy to quantify.
4. Although data synchronization as a concept is simple for most of us to grasp, it is deceptively nuanced and complex to implement.  There are offline and online trade-offs around caching for performance and real-time access to systems-of-record that have to be considered as the device switches between WiFi and cellular networks.  Furthermore, each application has its own notion of data attributes, think an iPhone Contacts app record versus a Microsoft Outlook Contact record.
5. Apple corporation's notorious tendency to internally silo products and teams, likely make this type of enterprise-wide effort more difficult to anticipate and execute, even assuming the appropriate corporate stakeholder prioritization is in place.
6. The smartphone class of devices has, in this regard, become a victim of its own success and ubiquity, as it increasingly becomes the hub of our digital lives.  Ever more data management responsibilities -- mostly around our social, entertainment and financial well-being -- are being piled onto a device that was originally conceived as a simpler computer for the masses.

The first two observations are manifestations of the (in my opinion) misguided vision of an Apple-only ecosystem.

While I deeply admire Apple and even many aspects of the iPhone itself, I am underwhelmed and disappointed with some of the iPhone's content management (file/synchronization/backup) capabilities.  Here are some specific problems:

• Inconsistent photo and video synchronization behavior.  I have observed, across iPhone models running different iOS versions, the inability of the device to locally delete uploaded images and videos, even when explicitly instructed to do so.  As a result, the device becomes "gummed up" with copies of images that I considered archived, requiring serious detective work to resolve.
• App organization.  While it has improved over time, the device's ability to organize and locate apps remains quite crude.
• No unique device identifier appended to files.  This could help in a variety of ways during synchronization, upload, backup and organization.  At a minimum, it would help eliminate the possibility of file namespace collisions when multiple devices are archived to the same backup storage.
• Limitations of Apple ID model.  Authentication through an Apple ID governs the features and data available to an iPhone user.  For example, it controls access to data stored in iCloud and purchases made through iTunes.  However, higher level data abstractions, such as an Apple customer's family and device inventory do not appear to be properly accounted for in the underlying architecture.  This results in Apple's customers having to employ unnecessary and clumsy workarounds to share content.

I challenge Apple to think different again.  Below are suggestions on how to make an even smarter phone:

1. Offer an all Apple-ecosystem architecture and content management workflow that you (Apple) are able to simplify and optimize.  However, you must also offer a hybrid ecosystem architecture and content management workflow.  Most of us, in either or both our personal and professional lives, must straddle the Apple and non-Apple digital worlds.
2. Continue (and complete) your evolution away from client-installed applications (e.g., iTunes and iCloud for Windows) towards a fully cloud-based architecture.
3. Revisit the design that regards the Apple ID as the highest level data abstraction.  Consider the notion of a household entity that would allow multiple Apple IDs and devices to be associated, smoothing the opportunities to exchange and synchronize content.   
4. Make your pricing model, for both the Apple-ecosystem architecture and the hybrid ecosystem architecture, simple and transparent.
5. Provide the option for the device to "auto-organize" apps by categorizing using App Store attributes or user-defined tags or properties.

Hybrid Mobile App Development with Intel XDK

About a year ago, the lure of developing my very first app and the opportunity to partner with a group of extremely creative people finally drove me to take the plunge into mobile app development.  This blog entry documents the odyssey of a 25 year software development veteran into "uncharted waters".

Native versus Hybrid 

Traditionally -- it seems odd to associate that word with something that has been around for little more than 5 years -- all mobile apps were native.  That is, native mobile apps are developed directly for a particular target device family.  Specifically, a native app is developed for iOS devices and written in Objective-C or developed for Android OS and written in Java.  However, there is now another option; a so-called hybrid mobile app.  Hybrid mobile apps are developed without (direct) concern for the target device.  Instead, the app is written using standard web technologies -- HTML5, CSS3 and Javascript -- and "wrapped" in a lightweight, native WebView.  By using such technologies, we are promised portability.

As you might expect, the primary trade-off to consider when selecting between the 2 approaches is improved performance (native) versus greater compatibility (hybrid).

Mostly because I use these standard web technologies on an almost daily basis, and I have not touched any variation of the C language in over 10 years, plus the fact that I did not anticipate any particular need for blazing performance, I chose to travel the hybrid mobile app path.

Tool Selection

The incredible churn in the range, capabilities and even branding of hybrid mobile app tools was intimidating, making my second decision much trickier than the first.  I considered many of the tools recommended by a variety of technical websites including:

• app.js
• jQuery Mobile
• Kendo UI
• Sencha Touch
• Ionic
• Intel XDK
• Titanium Mobile
• Knockout
• Montage

For me, my first gate was cost.  If I perceived any possibility of an expense in implementing a tool, it was eliminated from the shortlist.  Out went Kendo UI.  Secondly, I looked at server/hosting complexity.  I also expected to use a pre-existing domain/host that offered no support for Angular or node.js.  Goodbye app.js and Ionic.  Thirdly, given my experience with them, I wanted to ensure that the tool offered tight integration with jQuery and Bootstrap.  Finally, I looked at intangibles.  Based upon some negative comments and my own lukewarm experience using it as part of a webapp project, I eliminated jQuery Mobile.

In the end, I think what really sold me on Intel XDK was the breadth of functionality provided right out-of-the-box and its intuitive workflow.  In particular, Intel XDK offered direct support for many UI frameworks, including Bootstrap, its own App Framework, and, later, Framework7.  It provided in-the-cloud support for backbone.  It included a slick way to test and integrate web services.  The tool was tightly integrated with Cordova/PhoneGap and its family of plugins.  It offered multiple emulation and testing "modes".  It interfaced with each of these and more through an IDE that also offered a WYSIWYG builder.  I found the latter to be particularly useful during the first few months, trying to figure out the art of the possible.

Understanding Intel XDK's Project Options

Now that I had selected Intel XDK, I was then confronted with the selection of project options within the tool itself.   Like similar frameworks and IDEs, Intel XDK organizes solutions into projects (i.e., each of my hybrid mobile apps would have a corresponding project).  At project creation, Intel XDK presented me with a series of options that boiled down to this:

• Do I want to use Cordova plugins in my app?
• Do I want to build my app using the App Designer WYSIWYG builder?
• Do I want to base my app on an existing sample or demo?
• Which of the supported UI frameworks do I want to use in my app?

After a little experimentation, I arrived at the following answers:

• Yes; unless you are building a truly trivial (or perhaps totally innovative app) there is almost certainly a Cordova plugin that you can leverage
• Yes; in future, however, I might explore building an app without App Designer as its use can make for some tricky debugging and/or unnecessary code
• No; although it was useful to independently review the code behind some of the samples and demos
• App Framework; although I am already exploring the Bootstrap3 and Framework7 options

Apple Developer iOS Certificates, Identifiers and Profiles

There is also considerable set up required simply to allow your app be installed on iOS devices.  The dependencies are a little confusing but Intel XDK provides a guide, under the BUILD tab, that helps to clarify.  You need an Apple Developer ID with which you create certificates, define your apps, register devices (on which you want to test), and then generate a profile (typically, one per app).  This is all accomplished through the Apple Developer website.  You download the resulting profile file and install it into the Intel XDK project repository.  You then update the Intel XDK PROJECTS tab Build Settings to match the Apple Developer managed values (for App ID, App Name, Provisioning File, etc).

What Went Well

As previously mentioned, Intel XDK's focus on a soup-to-nuts solution really helped me to stay above water on a project that was my introduction to many terms, concepts and processes.  It really seemed intuitive and logical, to me at least, which is particularly impressive given the relative immaturity of app development.

I was also impressed with Intel XDK's efforts to provide responsive components out-of-the-box that I could easily test emulating multiple form factors.

I already had an inkling of the App Store Submission/Apple Developer process's labyrinthine nature.  Without Intel XDK's related guide, I might still be thrashing around trying to understand those dependencies.

The ability to easily deploy my app builds on device for "beta testing", before the actual App Store submission process, was a godsend.  I don't have any point-of-comparison, but I feel it unlikely that any other tool could make this more straightforward.

Not So Much

Even with Intel XDK's impressive breadth of functionality, I still needed to supplement my project development with:

• Issue tracking (I used Github)
• Authentication and authorization (I used Auth0)
• Backend tools (I used PHP and MySQL, for which I needed separate IDEs)

Lack of built-in source code control was, perhaps, the most disconcerting aspect of working with the Intel XDK.  I did see a couple of general references to integration with tools (Github again, I think), but I never explored how practical that is.  The need for this was underscored by somewhat frequent crashing of the tool itself, although it is fair to say that the frequency of such crashes diminished as subsequent upgrades to the Intel XDK were made available (currently, I have been through about 5 such upgrades).

There is an almost dizzying array of variations within the Intel XDK, some that seemingly overlap (for example, the options under the BUILD tab).  Some of that seems to be the result of Intel's purchase and re-branding of what was once referred to as AppMobi.  This general sense of confusion around the plethora of decisions and options is further compounded by the lack of a single unifying and coherent set of documentation.

Next Time

For my next round of mobile app development, I will certainly consider the Intel XDK again.  Intel seems to be providing the resources to maintain and update its features.  This is absolutely critical given the ever-growing list of competitors and the rapid churn in the associated technologies.  I will also take a second look at Ionic and React.js.  You can be sure that I will also see what other tools have emerged in mobile app development.  I fully expect there to be a bunch more.