June 2, 2017

WWDC 2017: What We’re Excited About

Just as our Rocketeers are coming down from Google I/O fever, Bottle Rocket’s iOS Engineers are gearing up for Apple’s 2017 Worldwide Developers Conference (WWDC). We’re sending some of our Rocketeers to the event where they anticipate announcements regarding Siri and many other surprises that present and potential clients can use to grow their businesses and further connect with customers. We’ve asked some of our Engineering Jedi (our lead engineers) what they hope to see at WWDC this year. Here’s Russell Mirabelli, Ryan Gant, and Josh Smith with expert insight (and plenty of tech talk).

Apple’s Siri-enabled Speaker

As a potential competitor to Amazon Echo and Google Home, this speaker is rumored to be powered by one of Apple’s own A-series arm processors and run a variant of iOS. It is also thought to use some form of Beats technology and support AirPlay. Expected to carry a premium price, the speaker could feature high-end audio with one woofer and seven tweeters built in. If Apple does release its own smart speaker, our clients could easily leverage the code already written in their iOS apps and bring them into the home. This could be yet another platform our clients could utilize, as it opens up conversational interactions between brands and their customers.

Utilizing machine learning, or SiriKit, within an app could make the difference between having the next new thing, or having an app that'll be outdated and underused in five months. So, brands should watch for the addition of a Siri-enabled smart speaker closely, since there’s a pretty good chance Siri will get some improvements to support it.

SiriKit Improvements

It's a safe bet that we'll get quite a few new intent domains for SiriKit, which will bring Siri integration into many new applications. When Siri expands, it brings with it a whole new way for users to interact with your apps. Imagine asking Siri for something and your app giving you exactly what you want. There’s a good chance Apple will expand SiriKit to include more domains outside of the current Ride Booking, Messaging, Photo Search, Payments, VoIP Calling, Workouts, Climate, and Radio.

If these enhancements occur, we would be able to leverage Siri in both the speaker and on iOS devices in these ways for clients:

  • Order your favorite food with just your voice
  • Instantly play an episode of your favorite show just by asking
  • Determine the newest videos available on your favorite TV anywhere app (or what comes on tonight)
  • Ask Coca-Cola Freestyle to pour a saved mix by voice
  • Perform a search for a flight or hotel and book using only your voice

Developer Tools

Steel yourself—this is straight developer talk. Our iOS developers love new tools. We know what's next in Swift for this year because it's been developed in public, but it will be nice to have those updates rolled out to our developers. Object serialization being incorporated as a language feature has our iOS team excited—this will lead to more consistent code across all our projects.

And, of course, we're about to get some new goodies in Swift. Updates to the compiler will not only help with compile times but, with any luck, we'll also get more useful error messaging, which will increase development speeds and quality of life. Our Rocketeers would also love to see another one of Apple's main apps become more open to extension. Last year we saw a little opening into Apple Maps, and it would be great if they continued expanding that. Something else we hope for, but don't really expect, is easier keychain support. Some developers avoid storing data in the keychain because it requires some C-level API usage. Apple could revamp that interface for easier accessibility via Swift. This would serve all of Apple's users by ensuring that more apps protect user data.

One area that we might see some improvements is in the persistent caching of objects in a local store. Core Data, although powerful, is cumbersome to use in Swift, and writing your cache in a keyed archiver is prone to errors. It'd be fantastic to have a solid solution that's capable of adapting both NSObject subclasses and Swift structs into a lightning-fast storage file format.

This is exciting stuff! Is your brand ready for what may come from WWDC? Keep an eye on our blog for the latest from WWDC, or get in touch and share your vision for engaging your customers via mobile or voice.

November 21, 2016

Develop for the Future: Reducing Technical Debt

When we say “develop for the future”, we do not mean that you should develop apps that will be useful in the future – we mean to develop apps that are ready for the future. By watching for trends from platform providers, such as Apple and Google, and selectively adopting new development guidelines and features as they are announced, your app will be prepared for future releases. Getting an application ready to ship on a short timeframe or otherwise is great, but if you rush, cut corners, or do not plan for later updates, something as simple as a new OS release could cause major problems. A little extra time spent implementing these changes and ensuring everything is "as it should be" in the present can, and usually will, save a lot of time and money in the future.

To better understand the importance of preparing your app for the future, we’re going to take a look at a few past updates and announcements that resulted in full-blown initiatives – features that seemed almost trivial at the time, but are now practically platform standards.


Size Classes on iOS

Size classes originally appeared for iOS 8 in 2014. These classes worked with Auto Layout to provide a UI that would work properly no matter what the screen resolution was. This was a pretty significant departure for iOS, as that platform had previously enjoyed a very small number of screen size variations, which made it simple to design to a fixed size. There was some initial resistance from the community; after all, even though size classes existed, we could still design for the phone sizes. With the introduction of multitasking on the iPad in iOS9, however, the value for size classes became more apparent. Size classes allowed developers to build a UI that would work well even with the unpredictable configurations of a changing screen size. By paying attention to size classes when they first appeared in 2014, developers could be more prepared for changes that appeared in 2015.


Google Screen Size Buckets

In July 2011 Android 3.2 introduced screen size buckets. These buckets include constraints like a shortest width demarcation. This was just after the launch of Honeycomb when they realized that tablets were much more varied in size than phones and indeed phones were getting pretty big as well. The existing buckets like "normal" and "large" were too vague and didn't carry a guarantee of a physical size for developers. The shortest width buckets were based on the physical size of the screen measured in density independent pixels which are roughly 1/160". The next year saw the release of the 2012 Nexus 7 which sold like wildfire and popularized the 7" format. Now in 2016 we see multi-window multitasking where two apps are shown at the same time. A 10" screen size might be displaying a phone-sized UI. If you took the hint with the new buckets, you were in good shape for both events.


Android Apps on Chrome

At Google I/O 2014, Google quietly announced an effort to get Android apps onto the Chromebook. The first demonstration partner for this was the Evernote app. It wasn't a great experience and it was a little clunky. Fast-forward to 2016 and now publicly available Chromebooks run native Android applications right out of the box. Google has largely combined its tablet efforts with the Chromebook OS in something rumored to be called "Andromeda" a combination of the words Android and Chrome. Whether or not this name sticks, Chromebooks from several vendors are already capable of this type of functionality with 10" screens, capacitive multitouch, accelerometers, GPS and other sensors. These devices should behave like a lot like a full-fledged Android device and add the ability to take multi-window multitasking to a new level. Looking back at 2014, the reveal of Andromeda and first-class Android applications on Chromebooks isn't really a surprise.


Deep-linking and Google Assistant

Also announced at Google I/O 2014 were app-indexing and enhanced deep linking support. At the time this seemed to be related primarily to their desire to index the world's information and play a larger role in app discovery. That in itself is a strong reason to work on deep-linking your app and ensuring your website is set up properly for app indexing. Then at Google I/O 2016, they announced the creation of Instant Apps which would go directly from a search to taking action in a slice of the app. Also, Google Assistant can use these types of links to launch apps directly from chat. If your app and website aren't taking advantage of app indexing and deep linking, you are reducing your app visibility and ease of use.


Swift 3 and third-party frameworks

When we choose a third-party solution, including open-sourced solutions, we assume responsibility for maintaining those libraries. This has become an issue with the release of Swift 3.0, as some frameworks have been either abandoned or slow to update to the new language syntax. Since a project can't simultaneously use Swift 2.0 and Swift 3.0, you can end up with an unexpected level of technical debt as a result. The best solution to this is threefold: First, use as few of these as possible. Secondly, choose ones that have a significantly sized user community for the best chance that it's updated. Thirdly, if all else fails, truly understand how the framework works, so that you are ready to perform any language updates required. Note that this can occur with any language that gets updated, whether that's Swift, Objective-C, Java, or anything else.


Future-proofing is a process, not a feature - and is ultimately something that must be done on a consistent basis. This can only be accomplished by viewing one's apps as living entities – receiving regular updates, not only for features but to ensure they're taking advantage of the latest capabilities of mobile devices and mobile operating systems. By evaluating even the minor advancements of the platforms, one can see future opportunities and get ready to succeed with future environments without scrambling at the last moment.

Contact us today to learn more about future proofing your projects.

September 25, 2016

Bottle Rocket at 360iDev: CoreAnimation Using Swift Playgrounds

Recently, iOS Developer Russell Mirabelli spoke at 360iDev, a four-day iOS developers conference in Denver. During the event, Russell hosted a session titled “200: Better CoreAnimation Using Swift Playgrounds.” The session covered using Swift playgrounds to quickly iterate through ideas, an overview of CoreAnimation, and how to significantly improving on the edit/compile/test cycle to quickly create great visual effects.

“This summer, I was honored by my company and the 360 iDev team to be afforded the opportunity to speak at the conference this year in Denver,” said Russell. “[The topic of CoreAnimation is] an important topic to me— it’s about doing the basics well, and getting re-acquainted with technology that’s sometimes less well understood.”

If you want to get re-acquainted with CoreAnimation and get some hints on experimenting with layer effects and particle systems, follow along with Russell’s session through the project sources he provides.

At Bottle Rocket, we’re always honored to provide our expertise to the development community. Contact us today about our mobile development and design strategies.

September 25, 2015

Swift 2

In 2014, the Apple development community was excited about the introduction of a new programming language called Swift. Apple experts said that development with Swift would be faster and more efficient than Objective-C – simpler syntax, modern language features, great app performance and no more square brackets!

At Bottle Rocket, we took a pragmatic view of Swift. We evaluated the new language and implemented a few choice bits of code, but we found that trying to create world class applications using a language that is itself under development didn’t support the productivity and quality that our customers have come to expect.

Now in 2015, Apple has released Swift 2.0, and in fact the majority of the sample code distributed by Apple and demonstrated at WWDC used Swift.  Here at Bottle Rocket, we’re excited to get to work! The language will be open-source, allowing other developers in the community to contribute and improve it, so language stability will improve rapidly.  Apple has also added a new error handling model to ensure applications are robust and resilient.

Our iOS developers have been trained and are ready to start working with Swift 2.0.  We’ve started adopting it in our unit tests (which we use to programmatically verify the stability of our code) as well as in selected class extensions.  Once we feel confident that using Swift will make our projects successful, then we will begin integrating it into our clients’ projects.


Developer Insight on Swift 2

Since our developers will be working with Swift 2 the most, the following video is of our Director of iOS Engineering, David Palmer, with his thoughts on Swift 2.

Swift is exciting and still somewhat new. By prioritizing existing commitments and pursuing the newest technologies, our Rocketeers are ready to take on the future.

Contact us for more information.

© 2020 Bottle Rocket. All Rights Reserved.