Coding Archives - LunarLincoln

Nov

Onboarding other peoples code

Greenfield vs Brownfield

There’s nothing better than cracking open your laptop, selecting “New -> Project”, and starting to build an app. At this point your codebase is flawless, your app builds and runs in seconds, and there’s no tech debt. Every thing is in the right place, and you feel like you can conquer the world.

But there will come a time when you have to work with other people’s code. You inherit an existing codebase when starting a new job. Or you get a new client who has a working app that needs features added or production bugs squashed. Or you get the opportunity to rescue a project that’s over budget and timeline and needs to be shipped ASAP. Whatever the case might be, there’s an existing codebase that has perceived value and its up to you to add to it. So where do you even start?

Documentation

At LunarLincoln, we like to start by carving out some time to review the project. If there’s existing documentation, start there. Now that you’re working on the project, documentation is your responsibility. Make sure to update existing documentation if you find errors. If there’s no documentation, document things as you go. Then use the app like a real user would. Start making a list of questions as you go and work with stakeholders or previous developers to get answers to those questions. Having a good spec is the first step in contributing to an existing codebase.

Code Review + Red Flags

After you know what the app’s supposed to accomplish, dive into the code. Start by building the app from the latest commit that was deployed. Be on the lookout for red flags (and yes, document these as you go).

Red flags come in many forms, and you’ll get better at spotting them the longer you work with apps. Here are a few we typically look for when onboarding a codebase:

An egregious number of build warnings
A disorganized project structure
A few classes with a lot of code in them or a lot of classes with almost no code in them
Poor or inconsistent naming
Breaking the defined architecture of the app (i.e. if MVC seems to be the convention, having the view accessing the model layer directly)
Code that solves widely solved problems
Dependencies that have little to no community around them

Fix Something Small

From there, take a quick, deeper dive into the project to get a feel for working in it. A great place to start is trying to fix an existing bug. This’ll give you an idea of what working in the codebase is actually like. It’s impossible to fully understand a codebase that took months to build in a review lasting hours, but at least you’ll have an idea of how to set expectations moving forward.

Document + Present Your Findings

Once you’ve had a chance to review the project, make a list of things that need to happen to move the needle on the project (you were doing this as you went…right?). Then categorize that list by urgency. You’ll probably want to fix everything before getting started with new features or bug fixes, but some things will absolutely be more urgent that others. The important part is that you communicate what you find to your stakeholders, agree on a plan to fix things, and start producing value. For existing apps, try to remember that the app people are using in the wild was made from the code you already have.

Become the New Code Master

Switching developers on a project is an expensive undertaking. Save yourself a headache later by reviewing the documentation, app, and code up front. Then leverage the findings in your review to lay out expectations and a roadmap for continuing development on the app.

Jun

Don’t build it all. Picking a Platform.

Often a client’s first knee jerk reaction is to want to build their product on as many platforms as possible. “Our customers and our admins need to be able to access their account online and on a mobile app and maybe on a desktop program.”

And then when we suggest maybe only doing only one of those…they get…kinda hostile.

They think that we don’t believe in this big idea. Or we don’t want to help all their users. But, this isn’t it at all! By telling you no, what we really mean is that we want you to be successful! And successful when you’re a fledgling startup means starting small and focused.

We totally get it. You don’t want to miss out on an opportunity to connect with a potential user and their potential money just because they can’t access your product easily, but trying to build out multiple code bases without any initial customers or validation is a very. costly. mistake.

The first thing you should code up when starting a new product is an MVP…or a MINIMUM. viable product. Does building your first product for multiple users to access online, on phones, on tablets and on desktops sound very minimal? Nope.

So what should you do? Which should you pick? How do you even do that?

Don’t worry! We can take a quick look at a couple of different aspects to decide which platform is best to start with.

First let’s look at what kinds of tasks your product will contain.

Will your users need to type in a lot of text?
- This will mean your product needs to run on something that has a real keyboard. (Web or Computer Program)
Will your users need access to a camera or video? What kind of photos or video are your users needing?
- Is it candids like Snapchat (App)
- Or is it more meetings like Zoom (Web)
Do we need the user’s location? How accurate does this need to be?
- If we’re offering some sort of running, fitness, or habits product we’ll need an app that can offer that hyper detailed data.
- If we just need to know nearby items (think Yelp) then maybe typing in our zipcode on a website works.
Does this product need a really high level of visual polish or performance?
- Depending on its speed and visual needs, maybe don’t consider a hybrid app or web app for starting off.

Then look at where these kinds of tasks will be done.

Are they needing to do these tasks while out and about? (Phone or Tablet App)
How about offline/no service areas (Native Apps)
Is this daytime, office work? (Web Browser or Computer Program)
Is this an evening, couch activity? (Phone App / Responsive Web)

Who will be using this product?

Kids? – Most kids use inexpensive tablets
Office staff? Maybe custom software or web service or inexpensive android tablets
Gen Z? New Moms? Senior Men? – Each demographic migrates to a certain kind of device depending on finances, habits, and age.

Now of course, people have varying habits and not every single user you talk to will say that they want to access your product in the same place. (In fact most users will say that they want more choice – even if their actual habits show them using the same devices over and over.)

So what you’re doing with this exercise is deciding which platform has the most logical overlap for all of these questions/answers for your target user.

Sidenote: Pretty much ALL of our advice at LunarLincoln involves touching base with your users and their needs. Make sure you genuinely understand your “core” user and remain focused on them. If you’re not sure how to do that just yet, check out our article on “Knowing your Users”.

Okay. I know more about where my users are and what this product might need, now what?

Now, pick ONE PLATFORM for your MVP.

Only one? Really? But…but…I can’t! I need them all. This way I don’t miss out and ALL of my customers are always happy. Please can’t we just build for web and mobile and desktop and tablet?

Nope. For your MVP, building for one platform will help you in a myriad of ways.

It helps save development time and money
It reduces churn when you need to change or tweak features
It even allows you to focus your marketing for that initial launch only in places and with groups that will use the platform you’re on.

These sound like good things right? Not doing ALL the things IS a good thing. I promise.

Also, just because you launch with one platform doesn’t mean you’re barred from expanding for all time. If you have amazing demand, then this means you’ll also have more money and information from users to know where to go next (build that Android app! Add that desktop version!)

If you over build and were *gasp* maybe a teeny bit wrong about your users, then you have a big ol’ technical piece that is getting dusty, is underused, and is likely still costing your financial resources to maintain.

Don’t be this creepy, empty castle subdivision in Turkey.

If you feel pretty confident about knowing what your user’s want and where they are but still need help determining the technical solutions, we’re happy to help.

Send us an email (from an app OR a website! 😉 )

Feb

Design for Fat Fingers

Have you ever had this happen when using your phone?

You typed in a ton of things on a page and then go to tap the submit button and your finger accidentally hits another button or link nearby? Or you weren’t able to type in the fields to begin with because you couldn’t get the cursor to move to them?

Screens these days are getting large and we can technically show a ton of things on there…but the thing is…our fingers are the same size they’ve always been (and not all of us have tiny hands like Donny T.).

A rookie issue when getting started with mobile design is making your touch areas too small or crowding too many things in one spot. (You can infinitely scroll, which means you have infinite space so chiilllllll and space that stuff out PLZ!)

Making things hard to tap makes users frustrated, and when they’re frustrated, they don’t return. BYE YOU GIANT HAND PEOPLE! I DIDN’T WANT YOU SHOPPING ON MY APP ANYWAYS. (That’s probably not what you were going for, but that’s what they think.)

So what SHOULD you be doing when designing buttons for mobile apps?

Luckily for you, you don’t have to go around measuring the finger tips of all of your potential users. Apple and Android have determined the optimal tap targets for you.

Apple’s Human Interface Guidelines recommend a minimum 44 x 44 px area while Android recommends 48 x 48 dp* when designing buttons for mobile apps.
(Let’s not go into the px vs dp discussion today but here is some reading)

Now that’s a good starting point but those are MINIMUM requirements. Actually the average human finger pad is 10–14mm and the average fingertip is 8–10mm, which mean you should be shooting for more like a 57px touch target. This is also backed up by tons of research. Check out Fitt’s Law if you want a deep dive.

That’s pretty big. Is my screen just going to be giant buttons?

Don’t worry! While it is good to have a decent button size not only for tapping but also for legibility/accessibility, you don’t always have to give that much visual weight. You just need that much spacing around your tap area so that there is no overlap with another actionable item.

Image courtesy of Material Design Documentation

When starting your mobile design make sure to set up sufficient padding around all of your buttons using the specs above for the tap areas.

Happy tapping!

Jan

A new look

Oh hi! You miiiight have noticed that things are looking a bit different at the online mooncabin. We decided that we were long overdue for a facelift, since we’ve been rocking the same look since 2014. The outside was workable but the inside was a bit of a time warp. Plus in the past few years we’ve been itching to add some new content but couldn’t figure out how to cleanly implement it with the old template.

The old template

Our old website was a wordpress template implemented before the invention of “page builders”. The inside was a scary land of stacked shortcodes. We didn’t like touching it because each time it required diving back into learning the mystery pseudo-code that stitched everything together. The template ceased being supported a few years ago but at that time we were mid-mobile-dev-mania and didn’t have time to look into alternatives.

What next?

So here we are: 2019. Web development has totally evolved, search engines are now super fancy/picky, responsiveness is key. Even WordPress, itself, decided to undergo a bit of a renovation this year. We’ve built a few other websites in the meantime and it’s helped me have a better idea of what we want and don’t want. We still recognize that we are better mobile devs than web devs, so we weren’t looking to build anything too custom. I’ve test driven several different page builders in the past: Avada’s Fusion Builder, WP Bakery’s Visual Composer, and this newcomer Tatsu run by Brand Exponents. I really dig the interface for Tatsu – it marries flexibility with simplicity and since it’s relatively new, it isn’t saddled with a ton of baggage/backwards compatibility like the industry leaders so we went ahead and dug in. Several iterations later – I think we have our final result.

What’s new?

EVERYTHING! Just kidding. Some stuff is really familiar, because its true and it works, but we did want to revisit how we talk about our work. We added a huge section on our Process. Building mobile apps is still a new concept to many people and “how does all this work” is the #1 question we get from leads. Dumping an entire load of process on someone in an initial meeting can be somewhat overwhelming, so it’s nice to have a place that potential clients can check out at their own leisure. We have a new area that focuses on our internal projects, which will grow in the new year as we add new ideas and ship more.

In the meantime, keep checking in. We’ll keep adding and polishing in the upcoming months, but I wanted to go ahead and kick off 2019 with some fresh code. Hope you like what we’ve built thus far.

As a side note: There’s really only one ongoing debate to settle – ARE THERE ENOUGH SPACE PUNS ON THE SITE? (Wiley always thinks there should be more.)

Aug

Sifting your User Research

So last we left you we were meeting with every meetup or conference organizer in the Metro-Nashville area. And then I emailed some in San Francisco for good measure.

When we’d meet, I had a giant list of questions that I’d generally attempt to cover during our chat. If we veered off into an uncharted area, no problem, but I typically tried to cover some of the same topics with each and every person I spoke with so that later I could compare and contrast responses. After each meeting, I’d “brain dump” everything we talked about into a text document. At the end of this I had over 20 pages of “notes” from organizers here in Nashville.

Welcome to Jennifer’s crash course in user research….

Did everyone say the same thing? Nope.
Did everyone have exactly the same issues? Nope.
Did you really expect every single person, to have the exact same needs? Well, no…but that would definitely have made this easier.

So how do I take all of this broad feedback and use it to come up with meaningful answers?

First I looked for trends…

What is something I heard from more than 3 or 4 people? Something that kept coming up without my asking or prompting?
What was the response when broadly outlining my idea? Tepid, interested? People will rarely, if ever, ACTUALLY tell you they don’t like your idea. They’ll just…kind of nod and make noncommittal statements about the idea instead of discussing how they, themselves would use it.

Now what are the trends amongst the people who offered similar suggestions or had similar responses?

Is it one specific kind of person or kind of meetup/conference?
Are issues noticeably split amongst different groups?
Are these suggestions/trends actionable, solveable, and from large enough demographics?

I discovered that those who, in a previous life, held a job that required them to be more social didn’t have as hard of a time going out there, hitting the pavement, and offering the right information to potential sponsors. I also noticed that organizers who had been doing this for a while succeeded through trial and error, or through helping with other local efforts like tech conferences where more experienced people gave advice.

All of a sudden our market for organizers who needed help with how to ask for sponsorship was smaller. It was looking like just newbies and those whose core competency was more solely focused on code versus people .

But, I DID have one piece of feedback that came up over and over from this more experienced group – “Once we’ve used up our personal connections, we don’t know who specifically to ask to grow our sponsorship” …not what to ask, or how to ask but WHO.

This was different from our initial assumption. (And why you do this process to begin with). And this isn’t feedback that we can easily solve with a simple solution. Which makes sense—usually the hardest problems are the most prickly. After some internal discussion we did determine that there were a few potential ways to tackle the “who to talk to” problem but none of them are super easy.

So now what?

We have to ask ourselves, can our potential product not only provide help to those with the “how to ask” problem (early stage meetup organizers), but begin to seed data and insights for those organizer-pros who have trouble with the “who to ask” part (veteran meetup organizers and larger conferences). Will our actual “value” be on the back end of the product and not where we initially thought?

In assessing your own user research ask yourself:

Are there still problems I can solve?
Can we still reach users with these pain points?
Is this still profitable? (Are there enough users with this pain point, is the solution reasonable to build, and will those users pay for it?)

For us, it’s time to go back to the business model and adjust our numbers. If not as many people are within our initial demo or willing to pay for the proposal product, can we get enough users in there to build data for a sponsorship leads product which seems more valuable to experienced organizers?

Next steps? We’ll attempt to broadly scope and estimate features for supporting the two types of users in order the reach profitability instead of just one. We’ll need to talk with organizers again now that we have firmer features in mind. And we should put some infrastructure out there to test the interest beyond Nashville (Product Hunt, Beta List, etc).

Aug

Testing the Waters – A New Product Idea

So you know how we were trying to “magic” an amazing idea last month? We made lists. We read books. We drew on the white board a lot. We looked at everything from Product Hunt, Beta List, and YCombinator. I even scrolled way back in the @BoredElonMusk Twitter handle (There are some great product ideas in there…that we’re not interested in building).

Well after weeks of being super negative about everything and thinking that we were never going to find anything good, we went on vacation to NYC. Then I went on a walk to lunch – gotta get my Turnip Truck Hot Bar fix – and I had an idea….

We host Nashville Cocoaheads. They have their meetings at our office. Sometimes we buy pizza or beer for them. One of their challenges has been finding sponsors. Mostly because they’re busy with their day jobs, not to mention sourcing the actual speaker part of the events. And this isn’t the only group. We’ve also had emails from friends who needed money for chairs for their usergroup. Like, a lot of chairs. Their event is super successful, hundreds of attendees successful, but we still ended up sitting on the floor one time. (We did give money for chairs the time we were asked and now they have amazing venue sponsors who have their own chairs).

This sucks.

My friends are trying to create wonderful things for their peers and shouldn’t be worrying about these small things. We’re sitting on the floor. Or drinking water instead of beer. Or rushing from the meetup to dinner because the organizer only bought 2 pizzas instead of 6 because they were paying for it out of pocket and now it’s 8pm and I’m super hongry.

Now I know the point of usergroups is not pizza…or chairs. But these things help. You’re tired at the end of the day, and you’re taking that little bit of energy left to go to a thing and learn something new. It would be nice if there was sustenance there, or even better…free tickets to a conference or a free pass to a new software tool. Congratulations on doing something extra – here’s another piece of help.

So, I got to thinking…wouldn’t it be awesome if there was a tool to help my friends find sponsors for their usergroups quickly and easily? They wouldn’t have to cold email. They wouldn’t have to figure out how to make a pdf with their sponsorship packages when what they care about most is being a really good software developer. They wouldn’t have to buy the pizza themselves or email their friends for help (even though we like to help).

But wait….

is this a real problem? Or are my friends just bad at organizing meetups?

So I sent quick emails to friends who are organizers along the lines of “What do you think about a sponsorship tool for usergroups…” I got responses back that were practically epistolary novels about how YES. YES WE WANT THIS. OH GOD. YES. and then 1,000 ideas of what it could look like.

Well then….let’s proceed.

So I wrote some more emails… a ton of emails actually. And I had coffee, and beers, and Slack convos. And… it seems like a problem a lot of organizers have. Maybe not always on the same dire level but it’s still a task no one likes but everyone needs.

Sidebar: I LOVE OUR LOCAL TECH SCENE and how amazingly patient and helpful all of the Nashville organizers and sponsors are. You guys make me want to build this thing immediately, if only to give back to those who have already given Nashville so much.

Currently, I’m still in the process of having meetings with the Sponsor side of the equation but I’m looking forward to it.

I think we might have found a winner you guys. We’re passionate about our local tech community (and other ones like it), this is something within our grasp to build (sorry, massive email sentiment analysis idea), and maybe just maybe it can be profitable (sponsorship help for podcasts, for school clubs, for little league teams, for any grassroots organizer of anything).

Next up. More meetings. Competitive Research. TAM and monetization. What does this idea look like in feature form? We’ll keep you posted.

Apr

Let it go – Building a real MVP

In Startupland, the most valuable product is the Minimum Viable Product (MVP). Why? Because you didn’t blow your entire budget/savings getting there.

People often come in and start throwing this term around “MVP”. Requesting something along the lines of: iOS and Android apps, a web portal, and a full dashboard for all users and grandma! Oh and an admin portal with state of the art features as well.

This is not an MVP. This is your wish list. Your nice to have list. Your 2 years in list.

“But…but… I NEED to have these things or I won’t be successful.” you say.

Hogwash. Success is based on building the RIGHT thing. Not ALL the things. I know it’s exciting to start building but slow your roll!

While it’s not too hard to trim an initial feature list down by pairing some low hanging fruit, oftentimes you’re still not at your target budget. You may need to drastically slash costs to get to market or not get there at all. At this point we’re not talking about removing 2 questions from the signup page or changing out how fancy search is, we’re talking about removing entire areas or better yet – entire platforms.

Prove your business model before investing in it in multiple tech stacks.

Do you rrrrreally need that admin portal for your 25 users? Can you hold off on Android to see if what you have in iOS is really what users want? Do users really need to have both web and mobile access?

What should I cut when I don’t want to let go?

1. Assess features & users to find platform launch targets

Where are your users hanging out? Are they older? Younger? Are they turning to the web for this service? Is this something they need on the go? Assess your audience and the core features of your product to determine whether this is a web or mobile play to start (you can add more entry points later! This isn’t forever!)

2. Sweat Equity for Behind the Scenes

Even the great and powerful OZ understood the value of manual effort.

Do you really need all the management stuff automated? Weigh your time versus your cost of development. Is hiring a $10 an hour intern to review applicant profiles cheaper than building a machine learning service? Can you keep track and manage payments with excel and quickbooks instead of a custom point of sale system? Only upgrade/build your tools when the workload demands it not before.

3. Tech debt can be your friend (in the beginning)

Don’t polish and deeply invest in a feature if it isn’t proven yet. High traffic areas can be improved upon once their value is clear. What if you spend half your budget on a feature that when launched collects cobwebs from your so-called target audience? Make pivoting painless with lightweight development decisions.

Infinite runway? A budget as deep as the Grand Canyon? You may not have the make these hard choices, but I would still advise you to do so. It’s healthier for a product to be able to grow based on real world user experience. Give yourself the flexibility to change features and change messaging without having to visit 6 different codebases and remove 8 months of work. A simple product launch isn’t easy or straightforward, but it’s a smart one to start with.

Still having a hard time slimming your MVP? We’re here to help! We love creating products that built for success and don’t have a problem saying no (or strongly judging you for not being able to say no to yourself).

Need someone to question all your decisions and make helpful suggestions?

Jan

Is Your App Idea Special?

Let’s be honest – app ideas are hard. The world is big and fast-moving and what’s hip today might flop tomorrow. Having what feels like a good app idea is only the first small step in building a successful product.

The Process

So, imagine you’ve dreamt up a great new app idea, what should you do? The very first thing any entrepreneur should do is check if their idea already exists, but not for the reasons you might think.

You’re not looking to see whether the door is shut in your face, you’re looking to see if the idea has potential in the market. Most app ideas are not purely original. Tons of people are having the same great idea each and every day. But that’s okay! Other people with similar ideas prove that it is a good one! Seeing competitors shows that there is a need and it is feasible concept.

Realistically, you ARE going to find a few apps that do some similar behavior to what you’re imagining. Whether those apps are wildly successful or quietly unnoticed, you’ll have to innovate and find ways to improve upon these existing products. Think about features that are missing, designs that can be improved, and new ways to monetize. Do you think this market has room for another app? How can you attract the most attention?

What if you go app hunting and can’t find anything even close to your app idea? In this scenario, your app idea typically falls into one of three cases:

Your app idea is original and nobody else has thought of it
Your app idea has been discovered to be too costly to develop
Your app idea isn’t appealing to enough users

Naturally, you want to be in the first category, but what if you’re not? This is hard, and you’ll likely need to reach out to potential users and gauge their interest. Continuing down this path is certainly risky but can still be very successful.

The Bottom Line

The harsh reality is that most app ideas are uphill climbs. You’ll work, you’ll iterate, you’ll advertise, and sometimes you’ll fail. Failure is a tough pill to swallow, but it’s a fantastic learning opportunity. Did you make a mistake when assessing the viability of your idea? Did market conditions change? Or did someone else beat you to the market while you were developing? No matter the outcome, use this experience to craft your next great app idea.

Oct

A Brand New Android Studio – 3.0!

There are few events in life that give developers such bliss and excitement as when their favorite tools receive a healthy refresher. Earlier this week the kind and hard-working folks over at Google released the official version of their long-awaited upgrade to Android Studio. It wasn’t an unusually long wait (Google seems to release new major versions roughly every 6 months), but the anticipation of diving into its new features has kept me watching Android Studio’s Stable Channel for months.

In the events leading up to Google I/O in May, the Android Studio team had teased the community with some incredible new features for Android Studio 2.4. Many developers, myself included, had our collective fingers crossed for a surprise release at the event and were shocked when Google announced official support for Kotlin in Android development. Additionally, they boldly nixed the 2.4 version of Android Studio from existence, bumped to a clean version 3.0, and continued pushing out numerous betas and release candidates. Now, many moons later, we’re blessed with a well-tested and feature-packed development environment ready for production use.

Without any further ado, let’s talk about some of those new features.

Kotlin

A few years ago, Kotlin burst onto the Android scene and was met with both praise and skepticism. JVM languages like Kotlin aren’t uncommon and most aren’t well suited for Android development (with the notable exception of Groovy, which Gradle uses). However, continued Kotlin development attracted more and more followers. Plugins were made for Android Studio and soon Kotlin became a common concept for cutting edge developers. Google must have been keeping its eye on Kotlin as well, and for the first time in Android’s history, Google announced full first-party support for another programming language to sit alongside Java (ignoring the NDK, since Google most certainly does!). Kotlin’s concise syntax shares similarity with numerous other languages, notable Swift, Apple’s preferred iOS and Mac OS development language. It addresses numerous Java shortcomings such as null safety, a lack of class extension functions, and easy threading support via coroutines. The full list of Kotlin features is long and you can read about them here!

Java

On the topic of languages, Java got some love this time around as well. For a multitude of reasons, Android’s Java doesn’t always have the same functionality as the base language. One of the most common criticisms of Java is its verbosity, especially with anonymous classes. You know, the ones you make to implement callback interfaces like View.OnClickListener. Java introduced support for lambda expressions, which are essentially abbreviated functions to reduce repetitive boilerplate code, in Java 8. However, Android struggled to provide support for lambda expressions; you had to use the experimental (okay, buggy) Jack toolchain or the 3rd party Retrolambda library. Finally, Android developers can use natively-supported lambda expressions. This is a huge plus for libraries like RxJava which rely on numerous single-method interfaces, making them prime candidates for lambda expressions and drastically reducing code length.

Android Studio

The last new piece I’ll talk about is an upgrade to Android Studio itself. For as long as I can remember, I’ve been using the Android Device Monitor to profile the performance of my apps. It was a little ugly and a little hard to use, but it got the job done. Google used its magic and transformed it into the Android Profiler. Earning a proud place next to the Build and Stop buttons, the Android Profiler button opens CPU, memory, and network monitors right within the Android Studio window and sits nicely next to Logcat and your other bottom toolbar menus. You can monitor performance, view payload information, find laggy parts of your apps, admire the very pretty interface this amazing suite sits within, and more. I’m eagerly looking forward to testing my apps and improving my code using these upgraded profiling tools.

I could go on but instead you should go download the new version of Android Studio yourself and play around!

Aug

Adventures in ARKit

Recently, at WWDC, Apple announced their venture into the world of augmented reality. If you’re wondering what exactly augmented reality, or “AR” is, it’s similar to virtual reality but instead of creating a completely virtual world for a user to experience, AR takes the real world, as captured by your camera, and places virtual elements into it – a la Snapchat face filters or Pokemon GO.

Apple supports AR in their latest phones with a new framework known as ARKit. This framework will allow developers to create some intriguing experiences through either SceneKit (which uses 3D models), SpriteKit (which uses 2D sprites), or Metal (which allows for custom rendering).

Building our first ARKit app

We at LunarLincoln thought this would be a great opportunity to explore the possibilities of AR. However, before we could do that we had to have the right tools which meant we had to upgrade to the new Xcode 9 beta and have a device running iOS 11 with at least an A9 chip which comes in the iPhone 6S and up.

Once we knew we wanted to do something with ARKit we needed to brainstorm some ideas. What would be a cool thing to throw into the real world, and what are the limitations of the software? A lot of time was spent scrolling through MadeWithARKit to see how people were using it.

The primary application of ARKit early on was creating interesting experiences such as showing a virtual rocket land on your pool, or a robot dancing in your living room. The other side of it came in the form of practical tools such as a virtual tape measure, or being able to place furniture in a room to see if it would look good or fit.

To get a feel for ARKit, our app originally started as an app where you could tap on the ground and a 3D model of some sort would appear. This was a nice idea and gave us a feel for the logic and programming behind ARKit, but it was boring.

The idea was presented to make an item rain from the sky. What if we applied the same logic where we tapped on the screen and something appeared, but instead of some boring 3D model, it was a rain cloud that showered money? Yaaaaaas.

The Make it Rain concept

We would use SceneKit and ARKit together to create a cloud wherever, and then let it rain money that would then pile up on the ground.

To get this app working the way we wanted we had to read quite a bit about one of the staples of ARKit: plane detection. ARKit uses feature points and plane anchors to find surfaces and mark them in 3D space. Once ARKit has gotten us this information, we can use that position to simulate the ground by placing a physics body there so that as the objects are falling from the cloud they will smack into the ground and stop. SceneKit physics controlled the falling and bouncing once objects hit the ground in addition to making a body dynamic with the appropriate category and collisionBitMasks filled out.

Looking at this app now, most of the learning and code came from SceneKit. ARKit, itself, was fairly easy to use. The worldtracking that fixes an object in space as you move around it is just one line of code (!!!). So ARKit gave us the ability to place objects into the world and realistic positions, but the bulk of the development behind this went into giving objects physics, making sure they collided, and that they were in the right position.

Final result?

So what’s the catch?

Working with ARKit presented several new hurdles to deal with. Debugging and testing with this app definitely felt strange. You frequently had to look up at the ceiling or back up and walk in a giant circle just to find where in space you have placed your 3D model. Getting sizes and perspectives correct was a challenge. A model might appear way up in the sky because at it current scale because it is the size of a cruise ship, but looking at it from your current perspective it looks to be the size of a car.

Another issue to wrap your head around is that the camera is the origin. If you decide to place something in space using fixed coordinates it will be relative to where you are holding your camera. Make it Rain had an invisible plane one meter down from the camera to catch anything that fell off of the edge of the floor plane and remove it from the scene. When I was testing the app sitting down, the raining objects were hitting the ground and piling up, but when I stood up, the invisible plane would rise above the floor’s plane and make the objects disappear before they touched the ground. This was a weird one that definitely tripped us up.

Beyond weird 3D space issues, there was the issue of finding good 3D models to use in the project. Finding free models that are in a format compatible with SceneKit, available for personal use, and that don’t look like crap is pretty difficult. SceneKit relies on Collada or .Dae files which aren’t particularly common. There were a few good sites out in the interwebs but Turbosquid was probably the best for finding models. That said, many ARKit developers dip into Unity for their models.

All in all this was an exciting project to work on and put out there. It is always enjoyable to explore new software. Especially one that lends itself to creating interesting experiences such as ARKit does. The current version not only rains money, but now has the exciting additions of sharks and stars.

We have a bit more polishing to do before public release alongside iOS 11 this fall, but we’ll be sure to make it available to everyone then. For now you can learn more about coding with ARKit here or here.

12 3 4 5