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.

May 30, 2017

Engineering Jedi: iOS10 – The 4s Awakens

With the introduction of iOS 10 in September 2016, Apple officially dropped support for the iPhone 4s, a device introduced nearly 5 years prior in October 2011. Following this news, iOS devs rejoiced! No longer would they need to continue supporting a device that was more than 5 years old and starting to show its age in terms of processing power, features, and available hardware sensors. Most importantly, no longer would they need to continue developing UI components and layouts that needed to gracefully adapt across four different screen sizes – 3.5”, 4”, 4.7”, and 5.5” – or so they thought….

Since the iPhone 4s couldn’t run iOS 10, it was easy to view that restriction as a blessing if you were creating a new app with a deployment target of iOS 10+. The UI could now be built to take advantage of the fact that your app would only be run using the 16:9 aspect ratios of the newer devices. Previously, it had often been very challenging to keep things simple when creating UI that looked good on both the smallest 480x320 resolution of the iPhone 4s and the largest 736x414 resolution of the iPhone 7+.

As you can imagine, this was our manner of thinking until just a few weeks ago when one of our client’s iPhone-only apps got rejected by Apple. The official rejection reason was that the app didn’t run at “iPhone resolution” when reviewed on an iPad. Specifically, Apple stated that the “app didn’t display properly” and referenced some screenshots attached to the ticket showing UI elements overlapping and running into each other. They also cited section 2.4.1 of the App Store Review Guidelines, which states that “iPhone apps should run on iPad whenever possible”.

It’s easy to forget that all iPhone apps can be downloaded, installed, and run on an iPad via the iPad’s “Compatibility Mode” feature. This was something that we did test before release, but only on the large 12.9” iPad Pro. The kicker here is that for all other iPad models, the iPhone app is run in its 3:2 aspect ratio. For the 12.9” iPad Pro, the app is run at the 16:9 aspect ratio that you get when you run the app on a 4”, 4.7”, or 5.5” device.

To correct the issue, we had to pivot quickly to adapt the designs and UI layouts to function properly on the 3:2 aspect ratio device. After again testing our iPhone-only app on three different screen-sized iPhones as well as the two models of iPads, we resubmitted the build to Apple and were quickly approved.

The unfortunate lesson here is that the 3:2 aspect ratio of the ancient 3.5” iPhones will continue to be a thorn in iOS developers’ sides for years to come. Our hope is that Apple eventually allows iPhone-only apps to run at the much more developer and user-friendly 16:9 aspect ratio by default on all iPads, not just the larger 12.9” iPad Pro. If Apple ever makes this change, then we can truly stop worrying about designing for the 3:2 aspect ratio devices when supporting the latest version of iOS. Until then, continue to develop your UI for iPhone-only apps such that it runs properly on all four iPhone screen sizes.

March 7, 2017

Understand Mobile and Web Testing with Bottle Rocket QA

Businesses need stable apps for their mobile experiences to impact users. That’s why Bottle Rocket clients receive one or more quality assurance (QA) analysts who participate in design and development. Our mobile experiences go through several stages of testing across all required devices. Here’s some insight on one aspect of that process.

With widespread adoption of mobile applications, the industry is implementing new kinds of testing. QA testers used to be primarily concerned with web apps. But even the most seasoned QA testers familiar with web apps will need to look at mobile apps with a fresh set of eyes. These applications can look and behave similarly, but there are more things to consider when testing mobile apps. There are core principles that apply to both, however. And it’s worth mentioning that there are many other kinds of app testing out there, but we’ll focus on these two for now.

Before we start with the similarities, here is a quick note for those unfamiliar with the concept of web apps: they are a client-server software application in which the client (or a user interface) runs in a web browser. People use them all the time: webmail, online retail sales, wikis, instant messaging services, among lots of others. Basically, any activity within a website that is more than just navigation and reading involves web applications. Just a few things to consider when testing:

  • Internal hardware
  • External hardware
  • Operating system
  • Browser compatibility
  • Network connectivity

Hardware and operating system combinations are something to consider for both web apps and mobile apps. There are many brands and models of desktop computers and mobile devices. Operating systems are constantly updating with new iterations – this is not unique to either web or mobile. Each update needs to be tested thoroughly with an app. Network connectivity is also a concern for both as wireless connections increase in homes, so web app users won’t necessarily be tied to a wired network connection. Outages and connection loss can happen, and behavior of both types of apps needs to be verified.

Mobile app testing involves the above concerns and then some:

  • Internal hardware
  • External hardware
  • Operating system
  • Browser compatibility
  • Network connectivity
  • Syncing multiple devices
  • Mobile network operators
  • Voice commands
  • Gestures
  • Device interruptions

The list could go on, but one of the key differences from the above list is syncing multiple devices. Traditionally, web apps need an internet connection to work at all. But some mobile apps allow the user to work offline and sync that data once the device is connected again. And now that smartphones and tablets are so common (and most people have at least one of each), connectivity and seamless syncing is important. If you carry a tablet with you that has a to-do list app installed and you leave it at home, what do you do? Access the app on your phone. All the changes you make on your phone will carry over to the original list on your tablet. There are many test cases around this topic. Are all devices supported? Do problems arise on some operating systems and not others? Can I sync between iOS and Android devices? Will changes made off Wi-FI be saved when a connection is restored? How long to wait to see a change sync to another device?

These are just a few examples to consider. Mobile-savvy testers that can write mobile specific test cases add tremendous value to clients seeking the most stable mobile experience that users prefer.

December 28, 2016

Low-Friction Development Environments

At Bottle Rocket Studios, we do our best to provide our developers with a low-friction development environment. We do this to help maximize productivity – for both our customers’ and developers’ benefit.

Elements of low-friction development environments

Developers select the tools best suited for a given task

Many projects will have predefined toolsets such as Xcode for iOS and Android Studios for Android, but that’s just the foundation. Developers doing the work should, whenever possible, select the tools they find work best for the task at hand. The only real exceptions to this are tools that may be a security risk or are undeniably less productive. Projects and workflows will vary, so the tools used in each should be expected to change as well. Flexibility has a low cost and can lead to a sense of ownership and comfort.

Developers are free to research new tools as needed

Since developers select their own tools, they also have the freedom to research new tools as needed. From interactive Slack channels to Google searches, there is no shortage of sites to leverage and each developer will have their favorites. This freedom of access will increase productivity. Developers will do what’s needed to get the information they’re looking for; reducing the barriers to doing so means they have more energy and time to spend on projects.

Open Communication

Open communication is a hallmark of low-friction development environments. A developer should never have to wonder the importance of a given task or where it fits in relationship to the project as a whole. Open communication must be practiced to be effective. An organization can't simply state that they value open communication; it must be demonstrated that communication channels are open and that asking tough questions is acceptable and encouraged. Without asking tough questions, developers don't get to deliver their best work quickly. Without answers to tough questions, the project is unlikely to succeed.

Developer-driven task sequencing

In a low-friction development environment, developers have the freedom to select the tasks that they will work on at any given time. This does not mean that the features and deadlines are subject to the whims of developers – it means that after presenting a set of requirements and a timeline, the person doing the work knows best how to accomplish that task. The developers best know how to sequence sub-tasks. This removes a significant amount of overhead and gives developers a sense of self-determination that leads to improved productivity and satisfaction.

Freedom to focus

One of the most vital things a developer can have in their work environment is the ability to focus fully on their work. This is not achieved through isolation or being freed from meetings – those come in a close second and third place. The most important thing to help a developer focus on the work is for the work to be meaningful and challenging. When a developer has a challenging (but not too difficult) task that matters to the completion of their project, they're more able to ignore distractions. Tasks that seem meaningless lead to distraction. It is important to present developers with directed challenges, or they will find their own. They will gravitate toward what they know and enhance or replace solutions to problems that were already solved adequately. Try to focus them on problems that provide the most value to the project like a UI feature that is orders of magnitude better than the norm instead of a slightly more efficient or succinct way to load images.

Benefits of a low-friction development environment

Higher Productivity

When the developer is free to use familiar tools instead of the tools everyone else uses, productivity will increase. As long as their tool is capable of producing standard outputs and follows the same process as the rest of the team, they will work faster and happier. It is important to keep in mind that any burden of converting the work to a team agreed standard format is incumbent upon the user of the unique tool. If the user of the unique tool can prove that it is objectively better and easy to use, the team may switch and evolve. If the tool is truly better, the whole team can eventually see a boost in productivity that rigid adherence to the old way would have prohibited.

Increased Job Satisfaction

A sense of self-direction drives job satisfaction. Being treated as a peer and not a commodity provides a sense of belonging and worth. Truly innovative developers are like good craftsmen – they’ll never be happy building the same set of cabinets over and over. It may be cheaper to build a spec home, but it will never make the cover of a magazine. Similarly, putting an experienced developer on rails and having them fill in templates will make them insulted, then despondent, then someone else's employee. Similarly, challenging developers with new problems or creative UI will allow them to stretch their skills and produce noteworthy software.

Being low-friction without being no-friction

There are drawbacks to having absolutely zero guidance for developers. For one, each project can be an experimental work of art understood by one or a few people. This is difficult for a maintenance team because they must learn to unravel the new flavor of the month used by the developer. A developer could also take a new direction and find it causes more problems than it provides solutions, putting the project in jeopardy.

Provide developers with challenges that keep them producing quality software without micro-managing them. Encourage them to evaluate the risk/benefit of using a new approach or tool. If the risk is high and the benefit is small or merely cosmetic, have them do a sample project on their own to prove it out. Review the solution and provide feedback. They might have just discovered a valuable new approach and the risk to a project was never taken.

Review projects to give them a health check. It is imperative that architectural review doesn't become a blocking portion of the development process. However, that doesn't mean you should defer the review indefinitely. Developers are generally receptive to meaningful and well-delivered feedback. This excludes seagull management where one flies into the room yells a lot and poops on everything. You should perform a considered, prioritized evaluation of the project with explanations for criticism and direction for solving the problem. Present this to the team lead and let them digest the changes and present it to the rest of the team.


Having a productive, low-friction environment for developers requires keeping an open mind about tools and approaches to software development. Good developers have some creativity and are eager to express it. Give them an ability and a channel in which to express it, and they'll be a long-term asset to the organization. Keep them challenged, but provide direction and monitor their ability to rise to the challenge. Guide them to innovate where needed, and they will produce high quality and innovative applications.

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.

© 2020 Bottle Rocket. All Rights Reserved.