Should I Be Using Swift or CloudKit for My iOS App?

Apple dropped two big surprises at WWDC 2014 directly at developers. Here’s a quick look at what they might mean for your app development.

Swift Programming Language

Since the beginning of iOS and Mac OS X, developers have been building apps using Objective-C, with a smattering of C/C++, and a brief flirtation with Java Cocoa.

This week, Apple announced Swift, a whole new language, developed in-house, which aims to be the successor to Objective-C for all Apple development work.

  • Compiles to native code sharing the mature LLVM compiler with ObjC
  • Modern language by design, feels like an alien hybrid of Python and Javascript
  • Uses ARC for memory management, not a runtime garbage collector
  • Tuned for performance and code safety, like a good modern language
  • Despite being compiled, has an interactive debugger that acts a lot like a modern script console that Python, Ruby, or Javascript developers will be familiar with

All indications are that Apple is not holding back with Swift, and I fully expect that within 2 years, the vast majority of new iOS applications will be built using Swift[1].

I recommend that all iOS developers start familiarizing themselves with Swift right away. Apple has a big-ass manual available for free on iBooks that gives the full language specification. And more learning-friendly books will no doubt be announced by the end of the month.

But don’t turn your existing development plans on their head just yet. There will be plenty of early-adopters building meaningful apps with Swift. Let them be the guinea pigs for now. Apple isn’t killing support for Objective-C anytime soon (in fact, the way Swift is built, Objective-C continues to share improvements in the underlying compiler and runtime.)

CloudKit

There was very little said about Apple’s CloudKit announcement. But I think it’s a very bold move, and not one that’s clear to pay off for Apple.

CloudKit appears to be a direct competitor to Parse, which was recently acquired by Facebook, and has been undergoing an identity crisis as it figures out what developers it’s actually going after. I know a number of developers who are fleeing Parse based on lack of customer support, scalability challenges, and distrust of Facebook as a shepherd for the platform’s future.

Apple is providing extremely generous limits for a free platform provider, presumably to be more aggressive in luring the first crucial customers to their cloud.

If I had to guess right now, I don’t believe that CloudKit will be wildly popular for the “serious” backend developer. It has three major limitations:

  • iOS only — the promise of building a backend API that will work with iOS/Android/Web is busted right from the start.
  • Unproven platform performance and support — Apple doesn’t have a great track record with cloud services themselves, so developers will be wary of trusting their backend to Apple
  • Proprietary technology — almost all mobile backends are built with open-source tech, which makes it easier to port them across cloud providers, and easier to hire developers with the skills to maintain/grow them

Could be great for you!

If you are building an iOS-only application that has modest cloud-data needs, or if you can’t find/afford a separate backend developer, but need your iOS team to prototype out the end-to-end app, a CloudKit deployment could be a great option.

Brent Simmons writes about this exact issue for iOS developers:

Design is what it does, how it works, and what it looks like. Implementation is what you do in Xcode. The back-end is — well, it’s, hrrmmm, something other people do? Or something we just ship without?

CloudKit is Apple’s proposal to solve backends for iOS developers.

If you are in this camp, a solo iOS-only developer who needs data syncing, or cloud backup, or server-side business logic, I recommend you seriously look at CloudKit. You’ll be on the bleeding edge for now, as I expect much slower adoption of CloudKit than of Swift. But the potential time-savings for a Platform as a Service offering that couples tightly to your native app development is a promise worth exploring.


  1. perhaps with lingering Objective-C scattered about, much as we used a lot more raw-C in the early days of XCode work.  ↩

What WWDC 2014 Means for Your App

In addition to introducing lots of interesting consumer software features, Apple’s Worldwide Developer Conference 2014 was jammed packed with important announcements for teams building mobile applications. Here’s an early look at what these announcements mean to teams building iOS applications.

Design

Good news for battle-weary developers after last year’s major iOS 7 overhaul — the fundamental design language of iOS 8 remains the same. But we’re now two generations out from iOS 6, and if your app hasn’t yet adopted a new design, it’s officially feeling antiquated, and it’s time to invest that effort.

It’s also safer now to adopt some of the more obscure iOS 7 gestures, like swiping to take action on items in a list, and the back-swipe as a universal back button. Apple’s continued use of these gestures will make them both less opaque to users, and more expected in 3rd party apps.

Swipe UI
Swipe UI

Device Support

While no new hardware was announced at this WWDC, the writing is on the wall for continued resolution independence. All indications are that a larger iPhone is coming this year. And in the new XCode 6, the simulator has options for a mysterious “Resizable iPhone”, which tells me that developers should start making their UIs more fluid now, in preparation for more diversity in device aspect ratios.

XCode6 Simulator Options
XCode6 Simulator Options

As far as we know, all iOS 8 devices will be retina, which eases the burden of shipping too many different assets in your application. But it’s not impossible that new resolutions (e.g. @3x) will be introduced with upcoming devices, so be ready with high-quality vector art, while continuing to push more design elements into code.

App Store Changes

There are lots of changes to the AppStore coming

  • Video “screenshot” previews
  • App Bundles, to sell multiple apps at a special bundle price
  • Related searches
  • Explore Tab
  • Editors Choice badges
  • Trending searches
App Bundles
App Bundles

I’m a bit concerned that these changes will add up to make the AppStore an even bigger popularity contest, especially those last three features. It makes discovery

Also worth noting is that a search in Spotlight will now return AppStore results, which could make a nice shortcut for prospective users to find your app in the store. I expect to see more apps advertising “search for us on your phone” if this feature works smoothly.

Custom Keyboards and Predictive Typing

Most of us are probably not going to build a custom keyboard. But app developers should be prepared to start testing their apps with 3rd party keyboards. Especially if you’ve been extending the top of the keyboard with custom buttons. Time will tell how well-behaved custom keyboards are, but no doubt some subtle bugs and usability issues will be lurking here.

Custom Keyboards
Custom Keyboards

If you have a text-entry-heavy application, spend some time with the new predictive typing as well. It’s still unclear how much control developers will have over the suggestions in their application (Apple says it’ll “learn each user and app”), but it’ll have an impact on your user experience for sure, and takes up even more space above an already bulky keyboard[1].

iCloud Drive

If your application deals with documents, or can open other document types, you’ll touch iCloud Drive somewhere.

In my opinion, this announcement is a lot bigger than the press it’s been getting. For the first time on iOS, we have something closer to a true filesystem. Users will begin to expect an experience more like they have on desktop, where your app can import, export, and support more filetypes stored in their iCloud Drive[2]. All file management in your app should be done using the new floating panel Apple provides.

TestFlight

Apple’s acquisition last February of the TestFlight service is starting to bear fruit. App developers can now run beta tests with 1000 users (and each may have multiple devices!) That’s a game changer for any large-scale beta testing effort. And it’s free.

The major downside is for cross-platform devs who would prefer a service that works with both iOS and Android, and who will probably turn to the fortunately-timed new beta distribution offering from Crashlytics/Twitter.

Extensibility

This is probably the biggest tectonic shift for iOS app developers since the launch of the AppStore itself. For the first time, the core operating system will support inter-app communication and services.

To date, most apps have been hacking around inter-app communications using custom URL-handlers, so other apps could trigger your app to launch with parameters. It’s worked surprisingly well, but is severely limited.

With Exensibility, your application can publish and consumer functionality that includes

  • Register your app in share sheets
  • Offer data and services to other apps
  • Create UI that can be embedded in other aware applications, like 3rd party photo manipulation tools that all camera apps can use

Remember to play nice with other apps in your ecosystem. Very few apps can afford to wall themselves off, and user expectations for interoperability are going to keep growing. Get out ahead of it with application extensions.

Widgets

Related to Extensibility, and even more immediately apparent to users, are Widgets for iOS. An ancient feature on Android, iOS is exposing widgets in Notification center, for things like weather and sports scores.

Along with Extensibility, this is a tool in the development arsenal that you shouldn’t ignore! The opportunity to have your app present on the lock screen and notification center, visibly in the daily workflow of your users, is a privilege. Time spent crafting a beautiful and useful experience in your widgets will pay off in spades with user engagement.

Widgets
Widgets

TouchID

If you have secure data in your app, start using the TouchID API now to unlock it. Basically, anywhere you were already prompting for a password should optionally use TouchID.

For other personalized devices, this is great too. Like I should have to confirm my TouchID before a remote control app will open my garage doors, or show me my medical history.

Continuity

Apple is making big moves in the area of placeshifting, most noticeably with their new Continuity feature. But this is only relevant for Mac OS X machines right now.

If you are building productivity, creative, or developer tools, you likely have a disproportionate Mac user base. We will start to expect integration between iOS and desktop, and I suspect that at least basic support for this will become table-stakes for high-end multi-device apps.

You can get away with ignoring Continuity in a new app for now, but expect users to bug you about it.

Location Aware Apps

Not specifically mentioned in the keynote, but reported by AppleInsider, app developers who also have a brick-and-mortar presence, can use iBeacon technology to put shortcuts on user homescreens when the iPhone is in the proximity of a store.

Location-Aware Apps
Location-Aware Apps

This won’t be used very often, but it’s an important trojan horse to what I expect will be a future holistic iOS payments system.

Metal, SpriteKit, SceneKit

For game developers, Apple continues to lead the pack. With improvements across the board, there’s no question that iOS will remain the most popular mobile gaming platform for developers.

Even if you are a pretty serious 3D gaming developer, chances are you won’t use the new Metal framework directly. You are probably building your app with a toolkit like Unity, and when they release a version that supports Metal, you’ll automatically get the advantages in your app.

For casual game developers, SpriteKit and SceneKit are likely to substantially speed up your graphics and physics engine development.

Swift and CloudKit

These topics were worthy of their own post. See Should I Be Using Swift and CloudKit for my iOS App? for the low-down here.

What about HealthKit and HomeKit?

Obviously, if you are squarely in the health/wearables applications or home automation space, you are paying very careful attention to those elements of the WWDC announcements.

My guess is that for at least the next year, these features are going to suffer the same fate as PassKit, announced last year. There was a flurry of initial experimental support, but very few users integrated it into their daily workflows, and it has languished. Even power-users I know make very little weekly use of PassBook.

My recommendation is to watch curiously from the sidelines unless your core business relies on health or home features.

Resources

Follow the whole announcement with great photos and commentary at The Verge


  1. Particularly concerning for iPhone 4S, the last remaining “short” form-factor phone that will run iOS 8  ↩

  2. or Dropbox, Box, etc., via the new Extensibility features  ↩

Big Data: Still Like Teen Sex

Don’t worry if you are confused. The meme that big data is like teen sex rings as true as ever:

  • Everyone talks about it
  • Nobody really knows how to do it
  • Everyone thinks everyone else is doing it
  • So everyone claims they are doing it…

A recent FT article gives some nice color to the realities of the “big data revolution”. More to come on ClearlyTech regarding big data, but now I finally have a place to link when I need to remind people of this apt analogy.

The Cloud – Elasticity

bungees

This article is part of a series on the defining value propositions of cloud computing platforms. The whole series includes:

The Stretchy Cloud

Another core tenet of cloud computing is its inherent elasticity, i.e. the ability to consume more or less resources on-demand, and through a pay-per-usage model.

Elasticity is a critical enough differentiator for cloud computing that Amazon even named their IaaS offering “EC2”, for “Elastic Compute Cloud”.

Autoscaling

There are two ways to take advantage of elastic computing resources.

  1. Exploit the ability to rapidly provision new resources whenever you notice demand getting high, expect an increase in capacity needs, or have a one-off task that would benefit from increased horsepower.
  2. Get a computer to do #1 for you based on some predetermined thresholds. For example, CPU load getting above 80% on your current servers.

Amazon Web Services, Rackspace, Microsoft Azure and others all offer #2, known as autoscaling.

I’ve found the real usefulness of autoscaling to be limited, and know very few companies that do it in practice. A now ancient (2008!) article by George Reese sums up some of the arguments against autoscaling, which still ring true.

If you have very specific application services that have predictable load patterns, or if you have so many servers that it’s worth a few engineers worth of salary to manage the complexities and assumptions of an autoscaling cluster, go for it. Until then, stick to scaling your infrastructure on the fly, but manually, to take advantage of your elastic infrastructure.

An Underutilized Feature

The elastic nature of the cloud may be its single most under-utilized feature. Most companies move to the cloud to save on infrastructure costs or to take advantage of managed services. And many use the elastic nature of the cloud to easily provision servers. But disappointingly few automatically scale their resources up and down to meet demand. something I suspect will change as the tooling for cloud platforms matures.

The best dollar value for cloud computing comes when you can exploit the elasticity to only pay for resources you need, when you need them. You win because you aren’t paying for what you don’t need, and IaaS providers win because they aren rent the same resources to someone else during the hours you aren’t using them.

Case Study: NYTimes

Despite being ignore by many tech companies, who just want the cloud because it’s a low-cost way to deploy an application, there are still hundreds (maybe thousands?) of companies that are making liberal use of the elasticity of Amazon and other big cloud providers.

The New York Times technology team has long been at the cutting edge of both front-end and architectural strategies. When it came time for them to put all their 11 million public domain articles online as PDFs, they took advantage of EC2 by spinning up 100 machines for 24 hours to crunch all the data. Let’s say they used m1.large instance types (just guessing), at a cost of $0.24/hour. That’s only $576 for 100 instances to run a whole day. A veritable super-computer for the cost of a low-end iPad!

I went to a talk a number of years back where the New York Times discussed the process of updating data on election night as poll results get uploaded to the Associated Press FTP server for consumption by all the media outlets. New poll results flow in once per hour, and time is of the essence when reporting breaking election results to your readers. So the NYT would spin up lots of cloud instances on election night to parallelize the process of slurping down election results every hour and updating them on their site. This was part of a much larger strategy for serving high-traffic on election night, all made possible by the elasticity of the cloud.

Case Study: You

Take a look at how your business uses infrastructure, and ask two questions.

  1. How variable is my utilization? How much money could I save if I turned machines on and off in-sync with demand?
  2. What cool stuff could I do if cost was no barrier to having hundreds of machines at my disposal for quick bursts? Is there a way to leapfrog my competitors by throwing computing horsepower at the problem?

Keep in mind that it’ll take a bunch of work for your ops team to figure out how to best exploit elasticity on your particular deployment. Make sure it’s a big enough lever for you before you send them on a wild goose chase. But know that the capability is there, and is one of the great benefits of the Cloud.

Do More Possibility-Driven Development

A top restauranteur spends countless hours discovering new ingredients, educating themselves on cutting edge cooking techniques, and dining at other top restaurants for inspiration.

With so many great libraries, services, frameworks, and templates out there, it makes more and more sense to allow all those possible tools to inform your design and build decisions.

I call this “possibility-driven development”.

Just like that restauranteur works with their chef on the best dining experience, you should be constantly familiarizing yourself with the latest trends in web development and tools, and working with your development teams to creatively apply them to your business.

  • When you see a site or app that behaves in a unique way, ask yourself “how’d they do that?”
  • When you read about a new service on Tech Crunch, figure out how your product would be different if you were an early customer of theirs.
  • Check out cool front-end techniques on sites like WebAppers, or Smashing Magazine and modernize your app a bit.
  • Keep an eye on trending technologies and play with the sites that use them.
  • And of course, read ClearlyTech where we’ll be highlighting great tools and trends all the time in plain english.

As a non-developer, you have a unique ability to look at new enabling technologies in an un-biased way. Take advantage of that, and open a dialog with your tech team. Find ways to integrate new technologies and services to make your product shine.

Thousands of open-source and commercial projects are finding possible ways to make your product great. It’s up to you to seize the opportunities.

How To Work with your Technical Advisor

A strong relationship with a technical advisor can benefit all early-stage founders who are building technology product, whether you are using a contractor, off-shore team, or full-time staff. And in later stages, a technical advisor can continue to be a trusted ear for you, and a useful resource for your own technical team.

Through my work as an independent advisor, and with organizations like Mass Challenge, Founder Mentors, and NEVCA’s Critical Mass, I’ve been a compensated advisor (cash and/or equity) to at least a half-dozen startups, a pro-bono advisor to a few dozen, and an occasional advisor to hundreds.

Finding A Technical Advisor

You want to find an advisor who has deep technical experience, especially in areas you care about (big data? user-generated content? mobile applications?) But skip techies who are coming to you with an agenda. You don’t want them pitching their pet technologies, but rather offering the best solution for your unique business.

Often, you can reach out to strong technical leaders (CTOs usually) at other startups in your area (or remote, doesn’t much matter if the communication skills are strong). Pitch them on your idea, let them know why you need their help. A genuine interest in cultivating the best technical operation you can goes a long way towards making us want to help you.

Also, take a look at communities like Founder Dating to find strong tech leaders who are looking to engage full or part-time with new ventures. Most of my full-time roles began as technical advisor relationships. You never know, but you might even find your next great co-founder if things work out.

Make The Most of an Advisor

No matter how you find an advisor and choose to structure an advisory arrangement, here’s some advice from an advisor’s perspective on how you can get the best out of us.

  1. Show a genuine interest in the tech and execution side of your business. We get excited by your entrepreneurial curiosity, and we’re proud of the tech and product experience we bring to the table. Ask us questions, dig in deep. We’re here to discuss with you, not to lecture at you. It’s not useful for anyone if we are spoon-feeding generic answers across the table.

  2. Do your homework. It’s demoralizing to be asked questions that Google can answer faster and more completely than us. Don’t ask “How do I set up a Google Apps mailing list?” until you’ve taken a swing at it. If you come prepared into a conversation, it’s more productive and enjoyable for everyone.

  3. Ask “Why” Since you’ve done your homework and have a sense of what your options are, we’re happy to tell you which option is right for you. Unfortunately, not nearly enough of my advisees follow up with “why?” You should want to know why that’s the best option for your business or for your team. Why should you want to know?[1] Because of teach a man to fish…, and because your tech team will respect you more if you understand the why.

  4. Teach Us Back. We’re not working with you for our health, or because of a community service court order. We think you are smart, interesting, and have something to teach us too. Make sure this relationship is a two-way street, and don’t be surprised when we turn the tables and start picking your brain in return.

Stuff to Avoid

Here are some lessons founders and I have learned the hard way. Heed these pitfalls and everyone will get more from the relationship.

  1. Stop Pitching Us. You wouldn’t believe how many times I sit down for coffee with an advisee, only to have them spend 45 minutes telling me all about how the business is progressing, what the latest product ideas are, how much money they are definitely going to raise, and why it’s all going to change the world. There’s a time and an audience for that, but you’ve just wasted a whole meeting with someone who was there to help you, and you’ve gotten no value out of it.

  2. Don’t get defensive. We are spending our valuable time helping you out because we want you to succeed. We aren’t a competitor, we aren’t your boss, and we don’t have a hidden agenda to sink your idea. If you succeed, we look good and we’re proud to be associated with your success. Take our advice for what it’s worth, and then implement it or not. You are running the show here, no need to get defensive.

  3. Don’t be excessively legal. Okay, so that doesn’t mean be illegal, of course. Rather, don’t start shoving NDAs and IP Assignment agreements at a technical advisor early in the relationship, or ever for that matter. Tech people are the most skeptical bunch when it comes to politics and legal mumbo-jumbo (we incorrectly believe we would never use such litigious instruments if we were in your shoes). If you do want to stamp an agreement to protect both parties, keep it simple. Check out the Founder Institute’s FAST for a good starting place.

  4. We’re not your code monkey. If you are secretly hoping that you can get your technical advisor to fix your team’s code, or to build some part of your app in their advisory hours, put that thought aside. I had an advisee who actually asked me to re-install Windows on a laptop in their office, a task I thankfully managed to side-step. Many advisors will be happy to establish a separate consulting agreement if you want to pay us by the hour to get more hands-on. Keep those two parts of the relationship separate and everyone will be happier.


  1. See what I did there?  ↩