Stuart Bradley is the founder and CEO of not one, but two companies – Carolina Speech Pathology LLC and Altaravision. We caught up with him on a busy Monday afternoon in between meetings, and he was gracious enough to take some time to talk with us about his experience as founder of Altaravision and the interesting journey of their flagship product, NDŌʜᴅ.

Put simply, NDŌʜᴅ is the most portable, high-definition endoscopic imaging system on the market today and an invaluable tool for speech pathologists. It has been extremely well received by the medical community, but its path from concept to market was not without its obstacles.

Where did the idea for NDŌʜᴅ come from? Because it is a very specific product.

It came from a need. Specifically, the need to be able to do machine vision on a Macintosh. Surprisingly, there really wasn’t any software that addressed it anywhere in the marketplace.

Would you mind just briefly explaining what machine vision is?

Sure. Machine vision is the ability for a computer to view imagery or an object, take that information and then display it. Essentially, it is a computer’s ability to see.

And the capacity to do that wasn’t on a Mac? That’s interesting.

Well, no. There was plenty of software out there, but it was all secondary purpose. The bigger issue was that nothing had the capabilities you would need in a medical setting.

It all comes down to video capture. All of the off-the-shelf software could capture images, but they suffered from significant lag. What you saw on the screen might be a full second behind what was happening in real time. That might not seem like much, but when you are dealing with medical procedures that kind of lag isn’t going to cut it.

I played around with off-the-shelf software for a number of years and finally found something I thought might work, but there were a ton of features that I didn’t want or need. I reached out to the developer to make me a one-off, but he was ultimately unable to deliver a final product. That’s what led me to Oak City Labs.

Once you had your software developer in Oak City Labs, what was the hardest part about going from this idea you had to an actual finished product?

By far, the biggest hurdle was doing it in a way that maintains compliance with FDA regulations. Jay Lyerly, the one who was doing the coding, knew that from the start and was able to work with my FDA consultant in a way that we could survive an FDA audit.

The thing is, FDA audits are worse than IRS audits and you’re guaranteed to get one, whereas IRS audits are random. As a medical device company, we are audited every two years by the FDA. Thanks to Jay and Carol at OCL, we’ve been able to pass every single audit with zero deficiencies, which is nearly unheard of.

Was there a moment when you got NDŌʜᴅ out into the world and thought “ok, we did it.”

Yea, there was. With FDA-regulated software you actually do have to draw that line in the sand. Unlike other software development cycles, where updates are always being pushed out, you can’t do that with medical devices. It has to be the finished product from the day it comes out. If you add features, it has to go back through the FDA approval process, which, as you can imagine, is pretty lengthy.

If you could do it all over again, is there anything that you’d do differently?

We bootstrapped the entire thing, with CNP essentially acting like an angel investor for the product. That was really tough, especially when there are people out there actively looking for good products to invest in. If I had to do it again, I would have taken the time to seek out some outside investment instead of just jumping in and doing it all myself.

When you think about where you are today as a business owner, is there anything that sticks out to you as the thing you are most proud of?

Honestly, being able to take on, create, sell and make an actual viable business out of a medical device when I had no prior experience in that industry. I had owned Carolina Speech Pathology for years, but the journey with Altaravision and NDŌʜᴅ was an entirely new one.

What’s your favorite part about doing what you do?

It has to be the satisfaction I get from solving hard problems, and the fact that it’s never boring.

Finally, whenever you have clients or colleagues that are talking about Altaravision or the NDŌʜᴅ product, what do you want them to say or know about it?

I want them to know two things. First, I want them to know it works, and always works. Second, that it is designed to be incredibly easy to use. If you can use Facebook, you can use NDŌʜᴅ.

For more on Oak City Lab’s work with Stuart Bradley and Altavision, check out this article Jay wrote on Computer Vision for Medical Devices via Core Image. If you have an idea and need a software development partner, or if you just have some questions about the development process, we’d love to talk to you. Follow the link below to contact us!

At Oak City Labs, we’re working more and more with computer vision (CV) and image analysis, so it’s exciting to see how others are using CV to solve problems. Face ID from Apple has garnered a ton of recognition in the past few months as they attempt to use CV to solve the issue of mobile authentication.

FaceID is a technology that Apple shipped in the fall of 2017 as part of the iPhone X. The phone projects a constellation of 30,000 infrared dots onto your face and the user facing camera reads the location of those dots. The phone can use that positional information to create a 3D map with enough detail that it’s unique (with a one in a million chance of false positives).

FaceID replaces TouchID, a fingerprint based authentication technology that is fast and relatively mature. I’ve spoken with some folks who lament the loss of TouchID in favor of FaceID. They miss the ability to unlock a phone with only touch without having to ‘frame’ their face, so the phone gets a good look at it. Others say FaceID is too slow, or doesn’t work consistently enough, falling back to manual passcode entry. While FaceID might have some rough edges in this initial release, in the long term, FaceID will win out over TouchID.

TouchID was a great stepping stone, enabling much better security with relatively low friction. But it didn’t work for everyone. I know several people who aren’t able to consistently unlock a phone with TouchID. In my experience, they all have small hands and slim fingers that don’t seem to adequately cover the TouchID sensor. The other group with TouchID issues all have “end of the world” type cases on their phones. These big, bulky, indestructible cases promise to save your phone from the harsh reality of a concrete world. While they do an admirable job, they often make it physically difficult to place a finger fully on the TouchID sensor, rendering it useless. These are the worst kind of experiences for a technology like TouchID, where they train the user that it’s difficult to use and unreliable.

FaceID solves a lot of these issues. By not requiring physical contact, having the “right size” fingers isn’t an issue. Neither is encasing your phone in drop-proof armor as long as the camera can still see. Other issues with FaceID, like taking too long or having to ‘frame’ your face for the phone are just growing pains associated with an initial release. FaceID is usually fast enough not to notice now, and in a few years time, it will be fast enough to be unnoticeable. I also expect the cameras to continue to improve their field of view so FaceID is effective at wider angles. As the software is refined and the hardware evolves, FaceID will only improve.

FaceID brings something to the table that TouchID simply can’t — continuous authentication. That’s the idea that authentication isn’t something that happens once when you start a session, but something that happens continuously as long as you’re using the device. You see a bit of this on the iPhone X with notifications. When a new notification pops up on the screen, it doesn’t have real content. The phone shows a “New Email” pop up, but no content or who it’s from. When you, the phone’s owner, pick up the phone and look at it, FaceID verifies you and the notification changes to show who the email is from and the first bit of text. Imagine extending this to third party apps like 1Password. When you’re looking at the screen, the passwords might be automatically displayed, but when you look away or put the phone down, they’re obscured again. You could also imagine an online testing service that could use continuous authentication to ensure that you’re the one taking the test and not your buddy who’s much better at calculus. We’re scratching the surface of all new use cases for security and convenience with continuous authentication and I’m very excited to see where we’ll go next.

As FaceID becomes commonplace, we’ll see it adopted in many devices beyond phones and tablets. Because it doesn’t rely on physical contact, like TouchID, it’s easier to see it adapted to devices like AppleTV. In the large screen, 10 foot interface, FaceID could be the key to finally having a seamless multi-user experience. As I approach the TV, I’m identified and verified and I have access to all my content. Kids in the house might be identified in the same way and presented with only their kid friendly content. And if we really want to jump ahead, imagine FaceID for your car, where it unlocks and starts because it recognize you as it’s owner.

TouchID was an incredible innovation in making devices more secure with less burden on the user. FaceID is the next step in the evolution of strong security coupled with ease of use. As this technology becomes a staple of our digital world, we’ll see it applied to more and more niches. As we develop computer vision solutions at Oak City Labs, we’ll be considering how we can incorporate this kind of ingenuity as we solve problems for our clients. If you have a computer vision problem that you need help with, let us know! We’d love to speak to you!


At Oak City Labs, technology excites us. We keep a keen eye on emerging technology and enjoy observing its impact on the world around us. For one of our last blog posts of 2017, I asked our developers for a technology that impressed them this year, and a technology they are excited about for in 2018. Read on for the results!

Jay Lyerly, CTO

Apple Face ID Oak City Labs Raleigh Durham Mobile App Development


Looking Back at 2017 – Face ID

Burgeoning from the recent announcement that Apple is investing $390 million into its Face ID and Airpod tech, the hype around Face ID has grown exponentially since its announcement at the iPhone X release event in September. Though it has had its troubles, Face ID is an exciting technology that pushes the boundaries of facial recognition and its plethora of applications. Jay is most excited about the idea of continuous authentication when it comes to Face ID.


Apple HomePod Oak City Labs Raleigh Durham Mobile App Development


Looking Forward to in 2018 – HomePod

A new challenger has appeared in the market for smart home connectivity. The Apple HomePod is billed as a “breakthrough home speaker” by Apple’s VP of Worldwide Marketing, Phil Schiller. Unveiled at WWDC 2017, the HomePod houses an impressive woofer, tweeter array, microphone array, and A8 chip. All these parts were specially crafted to fulfill Schiller’s definition of a successful speaker, which must: “Rock the house”, have “spatial awareness”, and “be a musicologist.” According to Jay, he is looking forward to “Alexa done correctly.” Them’s fightin’ words, Jay.

Taylor Harrison, Software Engineer

Looking Back at 2017 – Kotlin

Kotlin Oak City Labs Raleigh Durham Mobile App Development


For Android developers like Taylor, Kotlin is the newest hotness. Much like Swift is overtaking Objective-C as the programming language of choice for iOS apps, Kotlin is set to compete with Java as the main language for developing Android apps. In 2017, Kotlin gained 100% interoperability with the Java language and Android toolsets, and we are excited. By design, Kotlin is concise, safe, and gets along well with all popular IDEs. Taylor enjoys that Kotlin is less verbose than Java and is so excited about it that he wrote a blog post about it.

Looking Forward to in 2018 – Augmented Reality

AR Stickers Oak City Labs Raleigh Durham Mobile App Development


With Google and Apple announcing their new, updated AR platforms at their respective conferences this year, the world of augmented reality seems full of possibility for 2018. Google recently launched a Star Wars AR for the Google Pixel 2 (seen above) that allows people to appear alongside everyone’s favorite Galactic Empire. Apple recently released an awesome commercial featuring their AR technology, which appears to include placing a piano and other objects in the area around the user. From games like Pokémon Go to architectural design solutions, we fully expect 2018 to be a year of rapid growth for AR. The wearable market for AR most excites Taylor for the upcoming year.

Trevor Brown, Software Engineer

Looking Back at 2017 – Apple Machine Learning for iOS

Machine Learning iOS Oak City Labs Raleigh Durham Mobile App Development


What do Siri, your iPhone camera and your iPhone keyboard all have in common? All of these technologies use machine learning to create advanced user experiences. In order to bring these advancements to developers, Apple developed Core ML, a machine learning framework that can be used across all Apple devices. Core ML allows developers to create apps utilizing the thousands of hours of work and research that went into the machine learning used by Apple’s own products. Trevor is excited about the possibilities that machine learning opens up, including the ability to offload certain tasks to requests off the phone that get run through Apple’s machine learning framework. This, in turn, will open up the hardware on the device to be optimized and used efficiently while running the non-necessary tasks off the phone using machine learning.

Looking Forward to 2018 – Wearables Advancements

Apple Watch Oak City Labs Raleigh Durham Mobile App DevelopmentSmart watches are nothing new. According to certain estimates, the US wearables market is set to double by 2022. Announcements by Apple this year that the Apple Watch will contain more advanced sensors to be used to monitor health and promote good fitness practices. From keeping track of heart rate to measuring heart rhythm, the Apple Watch will provide an easy and convenient way of tracking many aspects of people’s health. Trevor is excited for the data gathered from these devices to provide more accurate data which can be used in studies to help the greater population. For instance, the tracking of blood pressure for diabetics and irregular heart rhythms to predict heart conditions.

Cory Scheviak (me!), Software Engineer

Looking Back at 2017 – Rust (Programming Language)

Rust Oak City Labs Mobile App DevelopmentWhile I, myself, am not a low-level programmer by trade, I have experience working with low-level languages such as C, C++ and Assembly. Through the grapevine, I learned about Rust, a systems programming language that, according to its docs, is focused on three goals: “safety, speed, and concurrency.” Rust was voted the Most Loved programming language of 2017 on Stack Overflow for the second year in a row, and continues to push to replace C++, the kingpin of low-level object-oriented programming. While not directly applicable to what we do here at Oak City Labs, it has been fun seeing an actual contender for replacing C++ come onto the programming scene.

Looking Forward to 2018 – Progressive Web Apps

Progressive Web Apps Oak City Labs Raleigh Durham Mobile App Development


My last blog post about Progressive Web Apps highlighted some of the pros and cons of the up-and-coming software ideology touted by Google as the future of webapps. Earlier this month, Google announced the release of an optimized version of Android called Android Go. Optimized for devices with less RAM, Android Go contains a version of Google Maps called Maps Go, which is a progressive web app. While not as fully-featured as Google Maps, Maps Go provides a lightweight, offline experience for its users that runs efficiently on their weaker devices. I am most excited to see if companies like Facebook, Twitter and Reddit turn their websites into progressive web apps instead of building native, or if they choose to use a progressive web app ideology alongside their native apps.

2018 and beyond

Gadget technology witnessed impressive gains in 2017, with a large emphasis on wearables that streamline everyday processes and provide value to users. Similarly, both Swift and Kotlin (the future of iOS and Android programming, respectively) saw a great increase in focus from developers looking to match pace with cutting-edge trends. Data gathered from devices such as smart watches and home automation devices will continue to provide valuable insight into human actions and needs that will further shape the development of such devices. It’s no question that 2017 was an incredible year in technological development, and we can expect much of the same in 2018. Viva la technology!

A few weeks ago at the All Things Open conference I was introduced to a term I had heard a few times but had not done much research on: “Progressive Web Apps”. Wikipedia describes Progressive Web Apps (PWAs) as “regular web pages or websites but can appear to the user like traditional applications or native mobile applications. In other words, PWAs are websites that look and behave like mobile apps. Now, isn’t that interesting?

It appears that the main priority of PWAs is to combine the benefits of modern browsers and web development with the benefits of a mobile experience. Several checklists by Google Developers contain the requirements for being considered a baseline PWA as well as an exemplary PWA. They also suggest using the Lighthouse tool for “improving the performance, quality, and correctness of your webapps.”

The baseline PWA requirements are:

  • Site is served over HTTPS
  • Pages are responsive on tablets & mobile devices
  • All app URLs load while offline
  • Metadata provided for Add to Home screen
  • First load fast even on 3G
  • Site works cross-browser
  • Page transitions don’t feel like they block on the network
  • Each page has a URL

It is evident from this list of requirements that Progressive Web Apps are really aimed at providing a secure, modern online and offline experience, much like mobile apps. Let’s look at some reasons why people might prefer a PWA to a native mobile app.

Preferring PWAs


PWAs allow developers to leverage the search engine benefits of SEO practices. In this way, existing search engine SEO strategies can be employed in order to promote an app rather than App Store Optimization techniques.


One of the requirements for classification as a PWA is that is works across different browsers. This rule means that not only can PWAs be used on computers across operating systems, but on mobile web browsers as well.

Additionally, users don’t need to go through the process of grabbing an app install from the app store. This implies that developers also don’t need to go through the process of uploading apps to be reviewed by Google and Apple before releasing any updates. This, in turn, means instant updates for developers and end users.

Caching / Offline Usage

One of the typical benefits of mobile apps over web apps are the amount of storage you have access to. With modern Cache APIs, users can install their PWAs to their home screen and access the app offline without needing to download any additional data. This functionality mimics that of a mobile app and unlike most websites, allows users to use the app even without internet.

Push Notifications

The age of notifications is upon us. Hardly an hour goes by without receiving a handful of notifications from various social media networks, emails, messages, etc. PWAs bring this functionality to the web, allowing you to receive notifications straight to your device, whatever it may be.

Hesitations about PWAs

While there are many upsides to the growth of Progressive Web Apps, upsides I am personally excited about, I would be remiss if I didn’t address their potential downsides as well.


Because PWAs don’t receive the same sort of App Store review that Google and Apple require, developers can stick anything they want into their apps. This means that if a developer chooses to be secretly malicious, they could, and there’s no review process stopping them from doing so.


Web apps can do a lot, but they can’t do everything. There is a lot of functionality only able to be utilized by native mobile apps still. PWAs are gaining ground every day, and as such are growing in the number of previously native-only features offered. Despite their gains, however, native apps still have many features that PWAs simply don’t have the ability to accomplish yet. Check this site to see if the functionality you want to add can be done with a PWA!

Platform Limitations

Plain and simple, iOS likes iOS apps. PWAs are only as successful as the platform that they are to be used on. As stated above, PWAs are gaining support every day. Within a few years I fully expect PWAs to have a majority of the functionality normally afforded solely to native apps.

Final Thoughts

Progressive Web Apps are a wave. Whether they are the wave of the future is yet to be seen. The fact that Google is pushing PWAs should be a sign of things to come, as they are often at the forefront of web development technologies (See: Angular, Vue). It will be awhile before PWAs gain all the functionality that native apps currently have, but they are on their way. Batten down the hatches and ignore the naysayers – viva la Progressive Web App!

At Oak City Labs, we love our continuous integration (CI). In our world, CI means that we have a trusty assistant sitting in the shadows that watches for new additions to our code repository.  Any updates get compiled, tested, packaged and shipped off for user consumption. If something goes wrong, the team is alerted immediately so we can get the train back on the tracks.

Let’s dive a little deeper at the toolset we use for CI. For iOS and Mac development, it might seem like a natural choice to use Xcode Server and we did, for a time. However, as our project load grew and our need for reliable automation increased, we found that Xcode Server wasn’t meeting our needs. We switched to TeamCity with very good results.

Xcode Server, after several years of evolution, has become a solid CI server and has some advanced features like integrated unit testing, performance testing and reporting. The great thing about Xcode Server is the integration right into Xcode. You don’t have to bounce out to a website to see the build status and any errors or failing tests link directly to your code. Unfortunately, that’s where Xcode Server runs out of steam. It doesn’t go beyond the immediate build/test cycle to handle things like provisioning profile management, git tagging, or delivery to the App Store.

Enter Fastlane. When we first adopted Xcode Server, Fastlane was in its infancy, only partially able to cover the iOS build cycle. In the years since, Fastlane has grown to be a full and robust set of automation tools that blanket the iOS and Mac build cycle, reaching far beyond the basic build/test routine. As Fastlane developed, we pulled more and more features into our CI setup. We built python scripts to integrate various Fastlane pieces with Xcode Server. Eventually, we were spending a good deal of time maintaining these scripts. Fastlane, on the other hand, handled all the maintenance internally, if we would embrace Fastlane fully. There were also some pieces we had built by hand (Slack integration, git tagging) that Fastlane included out of the box. It was clear that it was time to wholeheartedly jump on the Fastlane bandwagon to drive our automated build system.

One hiccup — Fastlane really wants to drive the whole build process. This is a great feature, but it means we can’t realistically do that from Xcode Server. We were already using TeamCity for CI with our other projects (Python, Angular, Android) and it seemed like a good fit. TeamCity is great at running and monitoring command line tools and now with Fastlane, our iOS and Mac builds are easily driven from the command line. Fastlane also creates TeamCity compatible output for tests, so our unit test reports are displayed nicely in the TeamCity dashboard.  

Now that our build system is fully Fastlane-ed, we benefit from their rich library of plugins and utilities. It’s simple to compute a build number for each build and push that as a git tag. Success and errors are reported to the team via Sack. We can easily publish beta builds to Crashlytics and send production builds right to Apple’s App Store. Fastlane’s ‘match’ tool keeps our provisioning profiles synced across machines. There are even utilities to sync our DSYM files from iTunes Connect to our crash reporting service.

Having the CI for all our projects under the TeamCity roof also comes with some nice benefits. There’s a single dashboard that shows the status for all the projects. There’s one login system to manage. The TeamCity server queues all the builds, so if an Android project is building when an iOS project updates, the iOS build is queued until the Android project finishes. With separate CI servers before on a single machine, you might have projects building in parallel which push the memory and cpu limits of the build machine. Also, the artificially elongated build times could confuse the build server system that monitors build time.

Our fully automated iOS and Mac build configurations have been running in the TeamCity / Fastlane environment for almost a year now and we’re delighted with the results. The Fastlane team does such a great job keeping up with changes in Apple’s environment. On the few occasions that things have broken, usually due to changes on Apple’s end, Fastlane’s team has a fix almost immediately and a simple ‘gem update’ on our end sets everything right. Going forward, Fastlane and TeamCity are our tools of choice for continuous integration.

Hurricane season may be tapering off as we enter the last week of October, but the use of technology during all sorts of natural disasters shows no signs of stopping. As we all know, the United States experienced three powerful hurricanes in August and September (Harvey, Irma and Maria), each delivering an unprecedented amount of flooding and damage to the areas impacted. Then deadly wildfires ripped through the California wine country. Earthquakes shook Mexico.

Enter technology.

More than ever before, we witnessed mobile apps at work during these disasters connecting victims with the aid they desperately needed.

Zello, a free app that turns your iPhone into a walkie-talkie by using a WiFi signal when cell service was down, shot to the top of the App Store. And it was used by the “Cajun Navy” to rescue hundreds in Texas following the flooding by Hurricane Harvey.

Ride-sharing apps Uber and Lyft offered free rides to shelters for evacuees, while AirBnB used their platform to arrange free shelter for victims in the homes of hosts.

In Florida with Hurricane Irma approaching, residents were urged to flee north and as roads jammed with traffic, gas was in short supply and high demand. Florida Governor Rick Scott urged citizens to utilize GasBuddy, an iOS and Android app which typically crowdsources pump prices from users, to track fuel availability. Elsewhere in Florida, Tesla gave drivers of certain models an extra boost on their batteries allowing for additional mileage before needing to recharge.

More than a month after Hurricane Maria made landfall in Puerto Rico, the island is still largely without power and cellular service. But efforts from Google, Apple and AT&T within the past week have allowed some users to reconnect to cellular service through Alphabet X’s Project Loon balloons. Yes, balloons are currently helping provide internet to the island.

Both Apple and Android released collections of apps tailored for the disasters at hand, such as the Google Play Store’s Hurricane Irma collection.

In Mexico, two devastating earthquakes shook the nation and took hundreds of lives. But a new early warning app called SkyAlert has seen 5.8 million user downloads.

As wildfires ripped across California, iOS and Android app CAL FIRE helped residents prepare and provided real-time updates on the fire’s latest status.

Like most things in life, technology’s presence in natural disaster recoveries is not without blemish as CEOs of major tech giants are known to make a blunderor twoor three. However, it’s obvious that blemishes and all, technology will now always play a vital part in how we respond to devastation. In this article, former FEMA spokesperson Rafael Lemaitre admitted that in a post-Katrina world there is a part for citizens’ and the private sector’s involvement in recovery efforts. No longer do we expect or count on the government to handle it all. And, according to Lemaitre, tech companies…“could be a big help.”

Apple’s latest operating system iOS 11 released earlier this week! Ever since the features were announced at WWDC this past summer, our CTO Jay has been excited for the release. Top features he’s excited about? ARKit (look for this to make a big impact on the way we think about and build apps over the next five years), iPad productivity updates that will allow more users to abandon their desktops for the tablet and Apple Pay integration with Messages – coming “this Fall” – lowering the barrier to entry for many users who have yet to adapt the technology.

The release of iOS 11 also brought about a notable change that is worth sharing.

With its release, iOS 11 will drop support for some of your existing apps causing those apps to stop working altogether. What does that mean? Older apps that are still running with 32-bit architecture will no longer open or work once you upgrade to iOS 11. Only apps using a 64-bit architecture will work in iOS 11.

That may seem harsh, but the reality is that Apple has required all apps since June 2015 to be submitted using 64-bit architecture, so if you have an app that is still 32-bit, that means it hasn’t been updated in at least two years – yikes! Additionally, Apple knows that 32-bit apps occupy a very, very small percentage of App Store income so they have no real incentive to continue providing support for them.

What should you do if you suspect you might have an older 32-bit app? Before upgrading to iOS 11, check in your Settings to see. Then you can decide how to proceed. If you have a 32-bit app that needs to be updated and you’re in need of assistance, you know who to call.

As with any new OS release, it’s important to check your own iOS app thoroughly to ensure all features are working as intended. (Tip: use this article to help guide your testing and make sure you’re covering all the bases.) It is not uncommon to find small (or even large!) features here and there that didn’t fare as well as others in the upgrade. Providing bug fixes and sending a new release out to the App Store is always a welcomed solution to your users.

What are you most excited about with iOS 11? Let us know in the comments below!


Welcome back to this series! Last week, we started walking through a checklist of necessary steps to take before launching your next iOS app and reviewed all the details about your Product Page listing. Today we’re discussing how to effectively market your iOS app.

Marketing Your App

Before you even launch your app and long after its first release, marketing should be a top priority. The more awareness you can bring to your idea, the more users you’ll see downloading your app. Consider the following as a part of your core marketing strategy.

  • Website: Your online presence can begin with a simple landing page. Start by claiming your app’s domain and setting up a basic website with a contact form, social media links and a short description. From there you can expand with more content as you have it. Use your website to collect leads from interested users that would make good beta testers or want to be notified when the app hits the market.
  • Social Media Channels: Twitter, Facebook, Instagram, Tumblr, LinkedIn…the list goes on. Think through the social media channels your target audience are using regularly and start building a presence there. Before launching your app, use social media to share updates, behind the scenes details and sneak peeks, as well as solicit feedback and ideas on features. As you near your launch date, you should use social media to build hype and excitement for the big release. And once the app launches, remember to continue monitoring your social media to drive downloads and respond to customer feedback.
  • Press Kit: Depending on your marketing strategy, a press kit may or may not be a necessity. If you plan to pitch your app to get press coverage leading into your launch, a press kit is a must-have. Your press kit should be a one stop shop for bloggers and journalists who you want to cover your app. Make sure to include visual assets like your app’s logo and icon (in all sizes, resolutions and file formats), as well as screenshots and a demo video if you have one. Content such as your app’s description and basic business information (launch date, price, platform, etc.) is also essential to include. Remember your goal is to make easy for someone to want to cover your app.

Join us again next week as we close our series talking all about app analytics – a crucial step for long term success! Update: the series continues here.

As you are nearing the end of beta testing your iOS app and preparing for its submission to the App Store (and subsequent deployment out into the real world!), it’s easy to forget about a crucial part of your app’s success: the product page. Nothing has a greater impact on driving downloads and acquiring users than your App Store product page. Done correctly, your product page really can set your app up for success in the market. As you’re planning for the launch of your iOS app, make sure the following details are being thought through.

Your App Store Product Page Details

  • App Name: Your app’s name is pretty straightforward and by the time you are planning for its release, the name is likely already established. Besides your keywords, the name of your app has the single biggest impact on discoverability within the App Store. The name should be simple, easy to understand and descriptive of the service you are offering. Apple recommends name lengths should be limited to 23 characters or less (and caps them at 30 characters maximum).
  • App Icon: This is the first visual a user will see of your app in the store, as well as the long-term visual users will search for on their device to launch your app. The icon should be simple, focused and recognizable. More on Apple’s icon requirements.
  • Category: You can assign your app two categories in the App Store, a primary and secondary. Though most apps have an obvious primary category from the get-go, others have the potential to fall into a few different categories. Your primary category is what affects search rankings and discoverability, so choose wisely and think about where your targeted users are most likely to be exploring. More on Apple’s categories, including special cases.
  • Demo/Previews: A video demo or preview of your app’s core functionality is a great way to make a lasting impact on potential users and drive downloads. Videos should be short at 15 to 30 seconds in length and show your app in action. More on Apple’s Preview recommendations here and here.
  • Screenshots: You can (and should) add up to five screenshots of your app to your product page. The first two screenshots are shown automatically in search results if a demo is not present, so it’s important that they capture users’ attention and draw them into your product page for more information. More on Apple’s screenshot properties. First time creating screenshots? We’ve had a lot of success using Launch Kit.
  • Description: The first two to three lines of text are key real estate when describing your app’s functionality and features. Apple only displays this limited amount of text before appending a “more” link, which users are forced to click in order to reveal the entire text. When crafting your description text, bear that in mind and put your most compelling details first. As a whole, your messaging should provide an overview of your app’s functionality as well as a list of key features.
  • Keywords: Besides your app’s name, keywords play the most critical role in search result rankings. Apple limits your keywords to 100 characters total, including commas to separate words. It’s important to be strategic when choosing your keywords. Think through what search terms your target audience will be using when looking for an app like yours. Be specific and focused.
  • “What’s New” section: While not necessarily important for your launch, it’s worth noting that the “What’s New” section will be valuable real estate beginning with your first update. Here you should not only describe the changes, fixes and added features being released, but you should also use the space to strategically communicate with users.
  • Privacy Policy / Terms and Conditions: Apple, and the law, require your app to have a published Privacy Policy and/or Terms and Condition page if a user’s personal information is being “accessed, collected and transmitted” within and/or from your app. You must also gain a user’s permission before “accessing, collecting and transmitting” personal information. It is your responsibility to consult with legal representation to determine when a Privacy Policy is needed and what it should contain. More about Privacy Policies, including examples.

Come back next week as I continue this series on launching your iOS app with part two: Marketing Your App. We’ll be discussing creating a marketing website, social media, press kits and more! Update: the series continues here.

Well, that was exciting.

WWDC 2017 wound down last week. It’s been a firehose of information, mostly delightful, a little disappointing and largely overwhelming. I wasn’t a lottery winner this year, so I’m observing from the other coast and I’ve still got about a bajillion hours of video queued up to watch. It’s going to be a fun summer! But the first session I was sure to watch was the venerable “What’s New in HomeKit” to learn the fate of my Hopes and Dreams.

The news is mostly good. Here’s a quick rundown of my wishlist and whether Santa delivered this DubMas.

  • Better automation rules
    • Offset from sunset
      • ? Yes! Now you can create triggers for “significant events” with an offset, so you can turn on lights 45 minutes before sunset. “Significant events” seems to mostly be sunrise and sunset in the current release.
    • Follow up events
      • ? Yes! HomeKit now includes “duration events” which can act as bookends on something like a motion trigger. When there’s motion in the hallway, turn on the hall light and turn it off in five minutes. I’m not clear if you can make this a little more sophisticated and turn the light off if there is no motion for five minutes or if you’re limited to a fixed interval. But even so, definitely an improvement.
    • Limit rules to time ranges or scenes engaged
      • ? Yes! The specific example from the presentation restricts a scene triggered from a motion sensor to only fire after sunset and before sunrise. You can connect these time limits to either “significant events” (with offset) or to specific times. I believe you can also gate them based on an active scene, but my notes are slightly sketchy on that point.
  • Beyond devices
    • Interaction with iOS apps, devices
      • ? Nope. There was no mention of triggering apps or controlling your AppleTV from Siri on your phone. But all is not lost! More on that later.
    • Workflow integration
      • ? Nope. No mention of Workflow at all. I’m still optimistic about Workflow. They could easily integrate HomeKit support in an upcoming release which wouldn’t rate a pre-announcement at DubDub.

Other HomeKit Improvements

There were lots of tantalizing tidbits included in the presentation, all of which bode well for the future of HomeKit. In a lot of ways, they’ve been building a foundation for several years and we’re finally getting to the point of critical mass where we can go beyond a fancier X10 system).

Highlights of the other announcements:

  • Other new events
    • ? Presence based events
      • First person comes home
      • Last person leaves home
      • House is occupied or unoccupied
    • ? Threshold range events
      • Temperature is above 80 degrees
      • Temperature is below 60 degrees
      • Temperature is between 60 and 80 degrees
    • ? Events which recur on a schedule
      • Execute “Good Morning” scene at 7 am, but only on weekdays.
  • Protocol enhancement for bluetooth accessories which improve latency from several seconds to sub-seconds
    • A bluetooth motion sensor used to take three seconds to turn on a light. Now it can do it in less than a second.
    • Should be available as a software upgrade to existing devices — no new hardware needed.
  • Enhanced setup
    • If you’re scanning (or typing) the string of numbers printed on the device, you can do so now before plugging in the device. Personally, I’m not limber enough for the gymnastics required to scan the smart plug after it’s plugged in and powered up.
    • New devices can use QR codes instead of printed numbers. The big benefit of QR codes is that they can be physically much smaller, as small as 10mm x 10mm.
    • And the pièce de résistance — setup via NFC tags. Yup, finally. Tap the device and that’s it. I honestly don’t know why any new device wouldn’t use NFC “tap to configure”.
  • New categories
    • ⛲️Sprinklers! I’m surprised sprinklers are just now getting to the party. They’ve been low hanging fruit for automation geeks for 20 years.
    • ? Faucets! A quick confab at the office and everyone agrees on the killer use case — cooking chicken. Nobody want to smear salmonella all over the sink.
  • Authentication / Certification
    • Software authentication. Previously, all HomeKit devices needed hardware authentication which meant older devices couldn’t be upgraded and new devices had to include an extra chip, adding cost and complexity. For example, I suspect Wemo bailed on HomeKit support because of the hardware authentication requirement. A few weeks ago, they were back on board. Coincidence?
    • Non-commercial products can be certified for free! Hobbyists, students and the like can now access the technical documents and tools to build HomeKit controllable devices for free. Now (in my copious free time), I can build a garage door monitor out of a Raspberry Pi and control it with Siri! This is super exciting because it lowers the bar significantly for building and testing prototypes before taking it to market. I expect this to feed a niche corner of KickStarter very, very soon.

Was there anything on the wish list that we didn’t get? Yes, HomeKit for the Mac. All the discussions were aimed at watchOS, tvOS and iOS, but the Macintosh is left out in the cold. It’s probably a question of resource management. Mac users already mostly have an iPhone in their pocket or a watch strapped to their wrist, so it’s not a desperately necessary feature. And soon, they’ll be a Siri Speaker listening for any request in the house too.

That brings us to the Siri Speaker, now with it’s official given name — HomePod. (I actually love HomePod, but it seems a little more “space cadet” than I’d expect out of Apple Marketing.) The intro at DubDub very much focused on it as a spiritual successor to the iPod HiFi, although they didn’t call that ghost by name. This week, at least, they’re positioning HomePod firmly as a music device that you can talk to. As an aside almost, they confirmed that it would act as a gateway to HomeKit too. HomePod does usher in the next wave of AirPlay — AirPlay 2 — which supports whole home audio streamed from any device to HomePods and/or AppleTVs.

AppleTV and tvOS didn’t get much attention during the keynote, only that Amazon Video is coming this summer (finally). But among the other WWDC technology announcements, Apple signaled a major change from h.264 to h.265 (AKA HEVC) which includes better support for 4K video, a feature currently missing from my beloved AppleTV. In the fall, we’ll see a hardware update for AppleTV taking it into the world of 4K video, along with a 4K upgrade iTunes Store video content. I think we’ll see tighter integration at that point between the AppleTV and HomePod, which only seems natural. (Just watch the demo of Google Home and ChromeCast from I/O this year.) If HomePod can control the AppleTV, this will be the big reveal moment.

Overall, I’m really happy with the HomeKit announcements at WWDC. Apple is pushing forward and seems committed to the platform across (almost) all the platforms. The rules/triggers/scenes system has become more sophisticated and shouldn’t feel like a hindrance in iOS 11. We’ll have to wait another six months for HomePod to land, but at least we know it’s coming. I’m cautiously optimistic that a solid AppleTV update before the holiday shopping season will reinforce that appeal of the whole ecosystem. In the meantime, I guess I’ll start saving up for HomePods. Maybe they’ll come in a six pack.