It’s the era of all things tech, and medical companies are partnering with developers like never before. In 2021 alone, 90,000 new digital health apps were created.  Since the early days of Covid-19, digital health has continued to skyrocket and the results have been overwhelmingly positive. Research has shown that many patients are now making many of their healthcare decisions based on their access to digital health resources.

If you’re a doctor or entrepreneur in the medical field who is considering a healthcare app of your own, this post is for you! We’ve complied a comprehensive list on how to build your own healthcare app.

Determine what kind of Medical App You Want to Build

There are hundreds of approaches that you can take when creating a software solution, so it is important to narrow down a specific focus and determine what the purpose of your app will be. Identify a pain point or problem to solve and write down how your software solution will resolve it. For example, if your medical office is looking to streamline its training process for new employees, an online platform that includes training modules, videos, and exams would be a software solution. During the planning phase, you will also need to consider the necessary features to include in your first version of the app. You can determine this by categorizing your “must have, “should have”, “nice to have” and “next version” features.

Web or Mobile? 

Once you have determined the problem and solution, you’ll need to decide if the app will be Web or Mobile based. This will be one of your biggest decisions and we strongly encourage you to talk to the experts about this. Our team determines web and mobile apps on a case by case basis. There is no “one size fits all” answer to this question! There are pros and cons to each option, so it will be important to consider these four questions:

What is the purpose of the app? What is the budget? Who is target audeince? Why will this specific software solution stand out?

We would love to talk you through this decision – feel free to schedule a call with us! In the meantime, read our blog on Web and Mobile Apps.

Cross or Native Platform?

The next step in the development process is to consider if the app will live on a cross or native platform. To summarize, “native development is the process of building apps for a specific operating system like Android and iOS. Each system has a specific design language, integrated development environment, and guidelines…cross-platform development involves the usage of a single code base across platforms. The codebase is combined with OS runtime environments for execution. So, these environments interpret the app’s code at runtime and execute it.” Similar to the Web vs. Mobile discussion, there is not a single correct answer. Many factors determine this decision such as your budget, timeline, and goals for the app. It is recommended that you talk to experienced developers who can walk you through the differences and benefits of each option before you hand off your app to development. Read more about cross and native platforms here.

Design the App

Here’s where the development really comes to life! Wireframes display the UI (User Interface) or design of the software. There are two types of wireframes – low and high fidelity.


 Low fidelity wireframes include basic and static content to visualize layout of the interface. These wireframes are built with publishing software, such as the Microsoft Office suite. “Low-fidelity wireframes usually serve as a checkpoint for the product team and stakeholders at the beginning of the design process. They help teams visualize and test early concepts, requirements and design assumptions at the beginning of a web design project.”

High fidelity wireframes are extensive prototypes that include color, content, and interactive buttons. They offer a finalized view of the app. Though they are more expensive than low fidelity wireframes, they provide an accurate depiction of the product and allow stakeholders to see the style of the app and interact with the interface.

Development and Launch

Your healthcare app is ready for development, testing, and launch! The developers have all of the information they need to build the healthcare app. Keep in mind that medical apps require HIPAA compliance guidelines throughout the development process. We recommend that you reserve 10% of the project budget for HIPAA compliance protocols.

It’s important for you and any key decision makers to meet frequently with the development team to communicate any changes that need to be made throughout the process. You should feel empowered to be a part of the development, even if you don’t understand the “tech talk”. We always say that a sign of a good development team is if they can take complicated concepts and communicate them in a way that anyone can understand.

After development, it’s time to test the app and get it LIVE! Our team at Oak City always encourages our clients to spend a good amount of time using the app, asking questions, and making sure that each feature displays the desired behavior.


We understand that developing a healthcare app is a long and complex process – but it is worth every step. We believe that technology exists to make day-to-day tasks simpler. With healthcare apps, the potential to improve lives is unfathomable.

Are you ready to build your own healthcare app? Schedule a call with our team to get started!

custom software & app development

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!

Increase Your App Adoption

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.

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!


At Oak City Labs, potential clients often ask if we write apps using React Native. Why not? Isn’t that the fastest way to market — write one app for both iOS and Android? That’s the crux of React Native’s pitch. Don’t spend time writing two apps when you can write a single React Native app instead. As CTO of a mobile dev shop, I should be able to answer that, so I’ve started doing some research on what it takes to be a React Native developer. How does React Native compare to Swift/Java development in terms of efficiency, stability and maintainability? I’ll walk through some of the things I’ve found.

Just a note before we dive in: this article addresses the idea of writing apps for iOS and Android in JavaScript, focusing on Facebook’s React Native implementation, not to be confused with the reactive programming model, which may be a compelling alternative to the traditional declarative programming style.  Reactive programming is a topic definitely worth following.  


How many tools does a developer need to build an app? As an iOS developer, I live in Xcode, provided by Apple and designed to build apps for the Apple platforms. Well over 95% of my development time is spent in Xcode. Apple also provides Instruments, a suite of testing tools to examine memory, CPU, etc in your app. Occasionally, I use Instruments to track down a particularly difficult bug. That’s it — Xcode and a little bit of Instruments.

The situation for Android is even a little easier. Android developers use Android Studio, a tool provided by Google with the sole purpose of creating Android Apps. Features like memory analysis and CPU monitoring are built in, so there’s really just one hammer in the toolbox. Android developers live in Android Studio.

Now onto React Native. It’s hard to find data on the amount of shared code in React Native apps, but conversations like this one suggest it can be 80% or 90%. That’s still a significant amount of platform specific code. Let’s assume we’re building an average app that has at least 15% platform specific code.

React Native developers have a bigger hill to climb just to get started. According to their instructions, here’s the list of software to install to build a cross platform app.

  • Homebrew — A package manager that makes it easier open source tools on your Mac
  • Watchman — A utility from Facebook to watch the filesystem for changes and run commands in response to those changes
  • Node — A javascript runtime built on Chrome’s V8 JavaScript engine, often used for server-side JavaScript
  • NPM — Part of Node, this is another package manager for managing JavaScript components
  • react-native-cli — Command line interface for for interacting with the React Native environment
  • Xcode — Necessary for various iOS tools
  • Android Studio — Necessary for various Android tools

In this article, Tony Mann suggests you’ll need these other tools as well.

  • Flow — A static type checker for JavaScript
  • Chrome Debugger — Chrome’s JavaScript debugger which can attach to your React Native application
  • Babel — A JavaScript to Javascript compiler

Now you’ve got everything you need to build a React Native app… except a text editor, so find one of those too.

So here’s the rundown for setup requirements

Platform Number of Tools Required
iOS 2
Android 1
React Native 10+


Right out of the gate, the bar is set relatively high for a React Native developer to get up and running. If this were a one-time penalty, it would be easy to write off. One day lost to setup on a six-month project isn’t significant, but this represents a whole dependency tree. Any update in one component can have a cascade effect that forces upgrading other components. Maintaining this whole setup now becomes overhead that the React Native developer must deal with. This kind of yak shaving can regularly consume a day of developer time.

Writing Code

I’m an iOS developer, so I’ll address the writing of code as a discussion of Swift vs JavaScript. For the sake of brevity, let’s assume Java (or Kotlin) developers make similar arguments.

JavaScript is not a nice language. It’s stone aged tech compared to Swift. Ariel Elkin does a fantastic job in this article walking through the many technical shortfalls of the language. Some of the highlights include

  • Weak typing
  • Lack of optionals
  • Lack of functions signatures

Issues like weak typing and lack of optionals are specific issues from Objective-C that Swift was designed to solve. In my experience, we always struggled with nil pointer exceptions in Objective-C. A rogue nil was the root cause of the vast majority of crashes in our applications. These have all but disappeared with Swift. A whole class of very common crashes has been fixed by using a language that simply doesn’t allow it. The rare nil pointer crash now usually has to do with interacting with legacy Objective-C.

Strong typing, optionals, and other features of Swift let me quickly write expressive, memory safe code that won’t crash. The compiler makes sure of that. As Elkin points out, these crashes happen frequently with React Native. JavaScript for app development is a step (or leap?) backward technically. If our goal is efficient developers, we should empower them with the best tools available.

Testing is an integral part of our app development process at Oak City Labs. One of the best ways to encourage developers to embrace testing is making it as painless as possible. With React Native, developers get another stack of dependencies to maintain just to get the unit testing framework running. In this article, Carlo Francisco goes over the testing stack they use at Refinery29 to unit test their React Native code. It’s based on Jest and Calabash / Cucumber. Jest is a JavaScript unit testing frame. Calabash and Cucumber are used together for application level acceptance testing. Calabash and Cucumber (and any customizations) are written in Ruby. The actual Cucumber tests cases are written in another language called Gherkin, one of those terrible languages for non-developers which are still too difficult for non-developers and too weird and restrictive for developers.

It’s great that there are testing mechanisms for React Native, but in order to accomplish real testing, we’ve got to add another few rooms on to the house of cards we’ve built so far. Not only do we add more 3rd party JavaScript frameworks, but we can also tack on extra languages — Ruby and Gherkin — in order to implement application level testing.

Compare this to iOS development in Xcode, which provides XCTest for unit testing and XCUITest for application testing, all written in Swift. Likewise, Android developers have JUnit and Espresso for unit testing and application testing respectively.

Stability is definitely a casualty here, mostly because of the limitations of JavaScript. React Native also loses ground on maintainability as testing tools require more third party components be placed in our growing dependency tree. I worry about efficiency too since testing now requires a React Native developer to know even more languages.

Debugging Code

Finally, once the code is written and running, there’s always debugging to do. According to React Native’s documentation, there’s no one stop shop for React Native debugging. There’s an in-app developer menu that opens the door to turn on/off some debug features and provide an onboard inspector. Using the Chrome browser’s remote debug feature seems to be the most powerful way to connect to the React Native app and view internals. There’s also a standalone version of the React Dev Tools to use when you can’t connect with Chrome’s debugger. And finally, there are the native debuggers in Xcode and Android Studio when you need to debug pieces of native code.

Debugging apps written in the native language is much more straightforward. To debug a Swift app in iOS, run it from Xcode and debug. For an Android app, run it from the Android studio and debug. It’s such an integrated part of the development cycle with the native tools, it’s easy to take it for granted.

With no one definitive debugging environment, I worry about a React Native developer’s ability to efficiently track down a bug. I assume one would start debugging in one of the JavaScript console tools, but then you might have to jump to a native tool. As context switching goes up, efficiency goes down.

Tool Quality

I’d also like to comment on the tool quality. Much of React Native’s tool chain, react-native, npm, etc, is executed at the command line. While some developers will praise the hard core grit of the command line, (“Real developers type, not click!!”), I find that it increases the entry-level barrier for new developers and generally causes friction for developers at any level. Trying to remember the flags for subcommands of the react command line tool isn’t going to help ship an app faster. Compare that to a button or menu item in a more robust tool like Xcode or Android Studio. The cognitive load added by a bunch of command line tools is just another stone weighing down the React Native developer and causing efficiency to sink.

Adding It All Up

At the end of the day, the React Native developer needs quite a big toolbox to fit all their tools in. Here’s the list:

  • Homebrew
  • Node
  • Watchman
  • NPM
  • react-native-cli
  • Flow
  • Chrome-Debugger
  • Babel
  • Xcode
  • Android Studio
  • Standalone React Dev Tools
  • Jest
  • Calabash
  • Cucumber

In order to use all these effectively, the React Native developer also needs to have a working knowledge of these programming languages:

  • JavaScript
  • Swift/Objective-C (iOS native components)
  • Kotlin/Java (Android native components)
  • Ruby (Cucumber testing)
  • Gherkin (Cucumber testing)

The single platform iOS developer needs Xcode (and maybe Instruments) to write, test and debug applications in Swift. Likewise, the Android developer needs Android Studio to write, test and debug apps in Java and/or Kotlin.

For a shop that has experienced Swift/Java developers, it’s very clear to me that there is zero reason to switch to the React Native development stack. We’re concerned about efficiency, stability and maintainability. The enormous number of tools required for React Native along with the piecemeal nature of programming environment are going to tank the efficiency of an React Native developer. Even the world’s best JavaScript developer is going to face an uphill battle on this unlevel playing field. JavaScript as a language is the biggest barrier to stability. JavaScript, by itself, is a deal breaker for us. Maintainability is another worry with so many dependencies from so many sources and keeping it all playing well together. (Not to mention dependency on Facebook’s ongoing support after the incident.)

I believe in using the right tool for the right job. Writing mobile apps in Swift/Java is the quickest, most friction free path to shipping apps to customers. I can understand how React Native appeals to web developers, offering to turn their JavaScript experience into mobile apps, but there is no free lunch. It may work in the end, but JavaScript (plus a lot of frameworks) can’t match apps written in the native toolsets when it comes to quickly and efficiently shipping a high quality, maintainable native app.

Oak City Labs is thrilled to announce the launch of CurEat’s Android app to the Google Play store this month! CurEat, a restaurant discovery tool, is the vision of entrepreneur Steve Mangano. We are honored to have partnered with Mangano to also develop both the CurEat iOS app and cloud server, which launched earlier this year.

The CurEat team will celebrate the launch, along with the introduction of their new CurEat Experience Program, this Friday, September 1 from 6-9 pm in Raleigh at the offices of Google Fiber. The Oak City Labs team will be there and we hope you’ll join too! More information can be found here.

Want to know more about this project? Download the CurEat case study below and we’ll serve up all the details!

CurEat is available in both the Apple App Store and Google Play Store now!

If you’ve ever found yourself seriously thinking about building a mobile app, but have no idea where to even begin, this post is for you! In a world where it seems like everyone has an app idea, the truth of the matter is that there is plenty of room for innovation and new ideas in the marketplace. But to take your idea and make it a reality, you’ll need to keep the following in mind.

First: Market Research

At Oak City Labs, we’re passionate about market research and strongly believe that it is the key to your success. Before writing the first line of code, it’s important to make sure that your idea is fully thought through. And while market research is definitely the most strategic route to take when your app is still just an idea, it’s also the route that can end up saving you money in the long run.

To take that first step in getting your app idea off the ground, begin by doing some free research. That’s right: FREE! Using everyone’s trusty friend Google, you can find information showing you what your app idea’s total addressable market (TAM) could be. Along the way, you’ll find competitors and possible features. You’ll also start to refine what your app idea is and what makes it unique. We also encourage those in this stage of the process to talk to people and conduct Voice of the Customer surveys and, ultimately, create a value proposition statement. The goal with all of these steps? To help you refine your app idea, discover what makes your idea unique and set you up for success as you begin the process of building the app.

Next: Partner

After doing your fair share of research and being confident in your decision to move forward with building your app, it’s time to find a partner that can help bring your idea to life. When looking for a development company, we encourage you to prioritize the following:

  1. Reputation: How experienced is the development team? How many apps or custom software projects have they led or developed before? What do their clients have to say about them?
  2. Relationship: How are they planning to communicate with you throughout the project? Will there be weekly check-in calls? Will they help you flesh out your idea strategically, advise of feature prioritization, consult with you on growth strategies and more?
  3. Results: Are they going to be able to solve your problem? Is this partner able to help you achieve the results you’re looking for?

We created Oak City Labs to answer a lot of these questions – to give you the missing pieces to transform your app idea into a real, quality product that makes a difference. Our team has spent decades in diverse roles across multiple leading tech companies. From this experience, we understand how to deliver on all facets of the app creation process – from the technical considerations, to project management, to product-market-fit, and all the important questions you might not think to ask. We’ve learned these lessons so you don’t have to.

We know how all of the pieces of development fit together so we bring a fully informed approach to your final product. By building strong client relationships – guiding you through every step, valuing your feedback, and collaborating on the process with you – we craft the well-designed, marketable app that you want to build.

Then: Build

Assuming you’ve properly validated your app idea and selected the best strategic partner, it’s now time to begin building your app. The process involved can include everything from wireframing and user testing, to visual and interaction design depending on your specific needs.

At Oak City Labs we make sure to have a full feature list in place before beginning development. Then we prioritize the feature list to ensure that the most important things are built first. If budget or time becomes an issue, we always want to ensure that your high priority needs were taken care of in the beginning.

As development proceeds you should expect lots of testing through frequent beta builds provisioned by the development company to your device. And you should expect lots of testing on their end too.

Don’t Forget: Marketing

It would be easy to wrap up this post with the next step and call it a day. But the truth is that successful apps won’t take off and have a hope of succeeding if there isn’t a marketing plan in place. While your app is in development (and, quite honestly, long beyond that), you should be working on and executing your marketing plan. From a website to social media, and even press kits, your marketing plan can make or break your app’s chances for success.

Finally: Launch (& Rinse and Repeat)

It’s the finish line! Well, sort of. At the completion of the build and testing phase of the project, it will be time to launch your app and we’ve created a whole checklist to make this process successful here, here and here.

Once that first release hits the store, you should celebrate! What an accomplishment! But keep in mind that it’s really just the beginning. Following the launch, your app will need to be nurtured on an ongoing basis if you hope to grow your audience (and therefore your business!). You’ll need to address bugs, add new features, adapt to new technology challenges and much more.

As with any business idea, there’s a lot that goes into going from an idea to a bona fide product. At Oak City Labs, we love helping entrepreneurs make their ideas a reality. If you have an idea and think we’d be a good partner for you, we’d love to chat!

Increase Your App Adoption

The App Store is huge. Open the Store and you’ll have more than 2.2 million apps to choose from. Getting noticed when you’re a little fish in a giant ocean is one of the hardest challenges when launching a new app. One way to leverage your fledgling, but growing, user base is to help them spread the word by sharing your app with their friends. And one of the easiest ways to do that is by providing current users with a way to link directly to content within your app using Universal Links.

What are Universal Links?

Imagine you’re a user named Yoshi64 using our new app called Kart2K. You might have a profile page with a web address like We can make this a Universal Link by giving our Kart2K app permission to handle links for our app’s website Now when an iOS user taps on a link, iOS will open the app instead of opening Safari. Tapping on Yoshi64’s profile link will open the Kart2K app and show Yoshi64’s profile, making the link Universal! iOS users who already have the app will be taken straight into the native app. Those who don’t have the native app on their device will be directed to the web page.Since that’s a pretty high-level overview, let’s answer the question of how does this work in practice? As detailed in the documentation from Apple, there are two steps to making your app and website support Universal Links. First, on your website, you need to add an app association file. This is a simple file that enumerates which parts of your website should be handled by an app. The sections of your website are defined by matching paths – so basically sub-trees off the domain name. The corresponding apps are defined by their bundle id. You could specify several apps that were responsible for handling different sections of your website. In practice, you typically would only have one app, but there may be some sections of your website (marketing material, support forums) that you still want to behave as normal web pages. You also need to add an entitlement to your app that advertises which domain the app supports for opening Universal Links.

When your app is launched in response to a Universal Link, iOS hands the app an NSUserActivityObject which contains the universal link. Your app will need to be able to extract the link from the user activity and display the corresponding data. NSUserActivityObjects are also used for registering activity with Spotlight. This lets your app data show up in Spotlight searches which drives user engagement. Supporting a universal URL scheme and activity objects allows your app to easily adopt several discoverability features in iOS and is well worth the development effort.

So now you’re all set. Your app is primed and ready for Universal Links! Ship it!

What Could Go Wrong?

No Plan Survives Contact with the User


When you open a Universal Link in the app, iOS shows a button in the top right to open it in Safari instead.

If your user taps that link, it disables Universal Link support in your app! All future links will open in Safari instead. This is quite disappointing because it’s so easy for a user to do. A simple tap to see where that button goes now disables the entire feature. Now when you tap a link, you go to the website without a clue that you should really be in the app. If the user scrolls the web page back up, a link back to the app is revealed, but it’s certainly not obvious. Hopefully the user will stumble upon it.

Special Cases Galore!

iOS only respects Universal Links in some cases. Behavior depends heavily on context.

If you tap on a Universal Link in Safari, it works. If you copy and paste a Universal Link into Safari’s location bar, you get the web view. If you scroll the web view up, you get the hidden “Open in App” link like above, but it’s unlikely the user will discover it.

If you tap on a Universal Link in a Safari View Controller screen, it works, but if you programmatically open a Safari View Controller with a Universal Link, it doesn’t cause the app to open. Instead you get the web view, with no option to open in app.

Most third party apps use a Safari View Controller for links. If you post a Universal Link in Slack and a colleague taps it, Slack opens a Safari View Controller with the link, so you only get the web page again, with no option to open in app.

This all makes it very difficult for third party apps to offer strong support for Universal Links, even the ones that are really trying to “do the right”.

And the Special Snowflakes

At some point hopefully Apple will fix this problem with Safari View Controller and all those third party apps will suddenly play nicely with Universal Links. However, there are always holdouts — the special apps that feel they need to provide their own custom in-app browser.

The big standout here is Facebook. Facebook’s in-app browser is completely custom, likely to retain their ability to track the user for profiling and advertising purposes. Regardless of the reasons Facebook implements its own browser, it doesn’t support Universal Links. Facebook always opens the link in a web browser rather than redirecting to the app. If you tap the button to “Open in Safari”, iOS takes over and the link opens in the target app, but that step is a bit obtuse for users, so the experience is confusing, to say the least.

Since our goal is to allow users to share direct links to content and improve the viral growth of our app, the lack of support from Facebook is quite disappointing, since it’s a primary (if not the only) means of sharing for many users.

There’s a company called Branch that has a whole platform for linking content. They’ve got a lot of great content about which apps that work (and sometimes work) with Universal Links. We haven’t used their product but they have an interesting turn-key solution for all your deep linking needs.

Universal Links in iOS 9 and later are a great way to increase sharing in your app and put your users to work, recruiting their friends into your app’s user base.  It’s a win-win scenario, where you get more users and your current users can share links directly to in-app content they want to share.  Adding support for Universal Links in your app also opens up integration with other iOS technologies like Spotlight Search and Handoff. There are a few gremlins to keep an eye on and sharing via third party apps can be a bit hit or miss, especially with Facebook, however, all in all, Universal Links are a great way to provide a positive experience to your users and share relevant useful content to prospective users.

We’re in the thick of testing on a large project right now. It’s a (delicious!) new release that we can’t wait to share more about later this summer. While it goes without saying that any release, big or small, should be thoroughly tested, you can often find yourselves in crunchtime near the end of a project. That crunchtime can lead to the choice between meeting a looming deadline and thorough quality assurance. Today we’re sharing all about testing and why it’s so important for your mobile app’s success.

Testing 101

When we talk about testing your mobile app, we aren’t just talking about making sure all the buttons work. Thorough testing goes well beyond that!

At Oak City Labs, we begin testing as early as possible in the development process. We’re an agile shop, so we place a lot of value on getting a (semi-)working version of the app in front of our clients for review as soon as possible while development is still in progress. As soon as we have a working, somewhat functional mobile app ready, testing begins.

Our testing process is just that: a process – a very detailed and thorough process. Armed with our trusty QA Checklist, we thoroughly test the mobile app inside and out. We try to break it in as many ways as possible (better now than when in production!). We work through each and every screen in the app comparing it with the designs, testing it against our use cases, proofreading copy and looking at scrolling and swiping behavior. We check how the app integrates with other apps, we test push notifications, observe screen orientation and more.

I said before that we test each mobile app inside and out. More than just a common phrase, we really do test inside our mobile apps. On the “inside,” we evaluate performance by testing battery usage, install/uninstall process, loading, network connection and the list goes on!

We also place priority on testing the app from the perspective of a first time user. As we near release, it’s all but certain that we’ve been using and testing the app for months. It’s important to take a step back and evaluate the app with fresh eyes to make the user experience for those who interact with it for the first time is optimal.

Why It Matters

You may be saying, “Wow, that seems a lot of work! Is it really worth it?” The answer is YES! Statistics tell us that about 25% of users use an app once and then never use it again. Add in crashes or a mediocre performance experience and you are sure to see that percentage rise.

Trying to break into a crowded market? There’s no easier way to differentiate yourself – in a bad way – than with an app riddled with bugs and performance issues. We’ve shared before about the importance of reviews for your mobile app and negative reviews left by customers frustrated by an untested app aren’t a great way to start.

Testing matters. At Oak City Labs we place high value on thorough and complete testing before a mobile app’s release. If you are looking to create a mobile app – one that is sure to be thoroughly tested – we’d love to hear from you!