Posts

In our previous post, we learned what the Agile methodology is and how you can apply it to your team environment. We quickly mentioned two words (Kanban & Scrum) that are a part of the Agile process and drive the progression of a workflow. Today, we will introduce Kanban and Scrum in greater detail and walk you through each framework.

Let’s start with Kanban…

Kanban is a framework for managing and improving the workflow within a system. Kanban is the combination of two Japanese words, Kan (“sign”) and Ban (“a board”). In Kanban, user stories are represented as cards on a board with columns that distinguish the different stages of the development process. For our team at Oak City Labs, our user stories represent each task that must be completed for each software feature. The cards are filtered through the Kanban board, starting in the “Backlog” column and working their way through “To Do”, “In Progress”, “Testing”, and “Complete”. See an example Kanban board below:

Traditionally in Kanban, each column limits the number of user stories that can exist at one time, which helps prevent work from piling up in one stage of the process. This also encourages teams to limit their work in progress (WIP) and prioritize the most important items. By visualizing the flow of work, teams can identify blockers that prevent tasks from being completed, they can remove waste, and optimize their performance.

Now let’s talk about Scrum…

Scum is another Agile framework for managing and completing complex projects. It was originally created for software development, but it can also be applied to several other project types. 

Scrum commits its teams to complete an increment of work through sprints that vary in length, most sprints lasting between two and four weeks. The goal is to create learning loops to quickly gather and integrate feedback from both the team and the stakeholders. At the beginning of each sprint, the team holds a planning session to define the sprint goal and to identify the work items that will be addressed during that sprint. The team then works on those items during the sprint, holding daily stand-up meetings to check progress, identify, and resolve any issues that arise.

There are three main roles in Scrum:

  • The Product Owner who works with stakeholders or clients to create the vision of the product that will be conveyed to the team.
  • The Scrum Master who usually serves as a project manager to oversee planning sessions and daily stand-ups, and removes blockers that prevent tasks from being completed.
  • The development team who creates, tests, and deploys the product to the client.

At the end of the sprint, the team holds a sprint review to demo the work that was completed during the sprint and to receive feedback from stakeholders. The team also holds a sprint retrospective meeting to reflect and identify areas for improvement in the next sprint. 

Scrum provides a framework for teams to collaborate and deliver value to customers in a transparent and flexible way. It encourages teams to work in an interactive and incremental way, to prioritize work based on customer value, and to continuously improve their processes.

The flexibility offered by both Kanban and Scrum offers advantages to teams who want to adopt various aspects of each framework and incorporate them into their workflow. Each team and project has unique requirements and working styles. Kanban and Scrum allow teams to harness their strengths resulting in a more efficient and adaptable process, ultimately leading to better project outcomes.

Are you ready to take your software solution to the next level? Schedule a call with us today.

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.

Conclusion

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!

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!

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

Source: https://www.macrumors.com/2017/11/04/face-id-brothers-video/

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

Source: https://9to5mac.com/guides/homepod/

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

Source: https://kotlinlang.org/

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

Source: https://thenextweb.com/google/2017/12/11/force-strong-google-pixels-new-ar-stickers/

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

Source: https://hackernoon.com/swift-tutorial-native-machine-learning-and-machine-vision-in-ios-11-11e1e88aa397?gi=2c186ebbe699

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

Source: https://developers.google.com/web/progressive-web-apps/

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


Discoverability

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.

Usability

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.

Security

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.

Functionality

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!

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.

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.