Coding Archives - Page 2 of 5

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.

Jun

4H Pedometer Party

We recently partnered with the 4H Grow program and it’s coordinator, Andy Lantz to show their summer campers how mobile development works. Andy informed us that the kids had been wearing pedometers everyday for the past week and were recording their steps in their notebooks. Our mission was to figure out a way to take this data, and use it for a mobile project that would be interactive, educational, and fun.

First we had to come up with an app concept for the pedometer data. The idea was presented that we could take all of the steps of an individual with their height and calculate how long it would take for somebody to travel to travel to various places. Now, where would it be interesting to walk to?… Why not the Moon or Disneyworld?

We have the idea. What comes next?

Prior to building code we needed a plan and all plans start with drawings (also known as wireframes in the mobile app business). They were just some rough sketches outlining where all the labels would be, what they would say, where buttons would take you, etc, but they got the job done.

After some review and finishing touches the pencil and paper prototypes were handed off to Jennifer, our UI designer, to be given style and design that can serve as a road map for building the app in Xcode. For this project we decided to use stock elements that resulted in simple code. This would help get the app done in a short timeline and make it easier to explain.

The final UI looked something like this:

After looks, then comes code

We then built the UI in Xcode storyboards. While the surface looked good and matched the designs, there wasn’t any logic hooked up to it yet.

The next task was to think about the math behind the app. We needed to take average steps for the week alongside a user’s height and turn that into a distance traveled per day. We would then take that distance traveled per day and apply it to the various locations we had selected.

To get the distance a student would be traveling each step we did some quick Googling and came up with the number .414. This number is the fraction of your height that roughly equates to the length of your stride.

App Looks, App Calculates, App is Tidied for Play

Once the UI and math had melded together to achieve the desired result, it came time to think more about the code demo. We needed to review and look at the code in an approachable manner. Using a Swift Playground as a teaching tool seemed like an excellent solution. By putting some of the logic into a Swift Playground it would be much easier to show the students what exactly happening to their steps from when they first enter them into the app to when they get displayed at the end.

A playground is also great for sharing code with the students. All they need is an iPad and to download the Swift Playgrounds app. We created a google doc setup with the source code for the playground that anyone can copy and paste into the app to manipulate or play with.

On a sidenote: Swift Playgrounds are great resources for testing out code ideas and learning code in a simple manner. Check out these other Swift Playground projects here.

Demo Day

After the app and Playground were complete and ready to go it was time for the students to come to the office, learn about LunarLincoln, test out the app, and see how long it would take them to walk to the Moon.

After the students had gotten their data for the Moon we listed them out on the whiteboard and compared results looking for any interesting insights. Would shorter students take longer? What about students who walked more than others? In general we discovered that walking times averaged around 400 years for the campers!

Interesting Discoveries in QA

The app for the most part worked out great, all of the students were able to get their desired results, but afterwards they wanted to experiment with some fictional data. They began to either put in one step a day which resulted in it taking an astronomically long time to get to the Moon (pun intended) and the result field would overflow, or they would put in nines until their fingers got tired or the app crashed and again the result field would have issues. It was usually the latter.

Problems with this “creative” QA experience? The app had issues with integer overflows because we had assumed they wouldn’t walk more than 2,147,483,647 steps a day and thus: crashing. A great learning experience for both our intern, Logan, who built the app as well as the kids for their creative experiments.

Recap and Materials

The experience was challenging for our project lead – Intern Logan, and was educational and fun for the students. They were able to see what some of their favorite apps might look like under the hood, and see what goes into building a mobile app from the ground up. To go through the full presentation and playground: visit Lunarlincoln.com/4H

Jan

Native vs Hybrid Apps – Part II

We recapped the technical decisions of whether you should build natively or with a hybrid solution back in this post. But let’s be honest, native is “technically” always best. The real reason client’s opt for hybrid solutions comes down to one thing. Money.

Why pay for development twice when you can build it once? Right? riiiiiight?

Well, sometimes.

If your desired app is largely simple elements and displays content: like reader apps or lists or shopping or blogs then YES HYBRID! If your app only needs maybe one or two things that need native integration then PROBABLY HYBRID.

The catch with hybrid is that any part of the app that needs any sort of custom UI or native phone integration like maps or camera, etc is going to need to have a native-code bridge written between your hybrid solution and the source. Which means we’re back at native development twice (Android and iOS), and your money savings is starting dwindle. Remember this image? Also, that in-house .NET team you thought could whip this up in their free time? They might get a bit stuck at those parts.

When there are new updates to the operating system from Apple or Android these third-party providers need to write their own hybrid platform features to interact properly – causing you to be reliant on their timeline for upgrades instead of implementing code updates the day the OS is made public.

To recap the recap:

Hybrid is cheaper in that it often uses web developers (lower rate) and is mostly build once, use twice. Great for simple projects, first/test versions, or apps that generally are reproducing web content verbatim.

The caveats are that:

You’ll still need to build native bridges to more complex parts of the app (bye web developers!)
You are reliant on updates by your third party platform to maintain pace with new operating system updates (dependencies)
It still has those technical limitations of UI and responsivity (design award bummers)

I’m sure you’ll find lots of articles about both – we’re obviously a bit biased being an all native shop (…for now. Why hello React Native).

But sometimes, after listening to a clients needs, features, and budget, we still find ourselves recommending hybrid. Honestly! We want you to get the best value AND the best app! Success for everyone!

So take what we’ve said above and before and assess for yourself! Do some pro/con lists. Ask your mom. (Or don’t ask your mom but DO ask the opinions from many potential contractors). Read more than one article.

We hope at the end you come back and choose to build your app-baby with us (if its native 😉 )

Jan

Becoming A Mobile Developer

[message_box type=”info”] This week we have a guest post from new-ish LunarLincoln crew member Cory Wilhite. Enjoy! [/message_box]

Today there are a million ways to get started as a developer. From traditional routes like classes in high school and college to newer paths like coding bootcamps and self-taught routes through online courses, the resources are readily available to get into the world of programming. While we’ll go over the many different ways to learn about software development, we’ll also dive into why you might like being a developer.

Motivations

Technology is infiltrating every facet of our lives. With the phones we carry around, the computers we use, and now where even lightbulbs and refrigerators are computers, programming and computer science is the common thread that helps in understanding how the world around us works. Whether you’re interested in designing websites, mobile applications, building new uses for hardware, or even building tools for other developers there is something out there that needs creating. At the core of the many environments and concepts that involve programming is the common thread of logic, problem solving, and the desire to continuously learn new things. One of the more satisfying daily elements of programming is to find solutions for problems that you previously knew very little about.

Whatever your motivations are, its important to know what steps you can take to either get started or further your education as a developer.

Traditional Paths

Up until a few years ago, the most straight forward way to start down the path to being a developer was found in academia. A computer science degree at college, and even earlier with AP computer science classes at high school. These programs focus on everything between the fundamentals of programming languages, the most optimal way to write software, and what makes a computer function. While often not being directed towards working with any specific technology or language, a computer science program will give you a broad understanding of the ways to write software and how to conduct research on deeper computer science concepts.

Self Taught Paths

There are several ways in recent years to learn programming through websites and online resources. One of the first websites to start online interactive learning was Codecademy. They provided free tutorials that a student could follow along with by actually completing code challenges in the browser all while learning that specific language or technology.

This concept of online interactive learning has been expanded on by several companies (e.g. Treehouse, CodeSchool, etc.) which also provide in-depth videos and quizzes to go along with the interactive coding exercises. A commonality between the online coding resources is that they make themselves accessible by focusing in on a language or technology that you might want to learn.

If a traditional computer science program is a broad stroke of knowledge about computing and software, these online courses are precise dives into a specific topic. They can be great as an introduction to programming because they give you the ability to get hands on and complete projects right out of the gate. On the topic of motivation, the feedback of being able to see your work in working product is a great motivator. Each day there are more and more resources to take advantage of online.

Bootcamps

With the introduction and success of online learning resources, there is a new type of learning resource that could be classified as being in between self-taught courses and a computer science degree. 3 to 6 month bootcamps have been cropping up (Iron Yard, DevMountain, etc.) that offer crash courses in different paths within the software development industry. These paths are more directly focused on the common career paths such as web developer (back-end and front-end), mobile developer, and even offering courses in becoming a user-interface/user-experience (UI/UX) designer. Where websites like Codecademy will dedicate a course towards one language like Ruby or Javascript, these bootcamps will base their paths on diving into the technologies and tools used currently in the industry for a specific career path.

How I got started

For myself, I took a mix of traditional and self-taught education. In high school, I took advantage of a web development class when I was first starting to get interested in programming. This lead me to further that learning with AP computer science. One of the important motivators in those classes was that they each left me with something tangible and just enough knowledge to be dangerous.

In my web development class, the final project was open ended and I took advantage of that by learning how to build a flash website. In AP computer science, our final project was to build Pong in Java. I ended up going to college for Audio Engineering Technology, but I decided to make my minor computer science because of those classes in high school and the interest I had in computers and programming. In between high school and college for me, Codecademy was just launching. I took full advantage of the free courses they provided at the time to learn Javascript and Ruby. I also utilized another company that was just launching called Coursera that featured real semester long college courses for free. I took classes that interested me (like Digital Signal Processing, Calculus, Game Theory) along side the education I was receiving at the college I went to.

It was a desire to keep learning and building on the knowledge picked up in traditional classes that had me pursuing further education on my own. Even after getting a job as a developer you never stop learning new things. Learning from other developers on websites like StackOverflow or following high profile developers blog posts to see what new techniques they’re experimenting with or problems they’re overcoming provide a deep community of knowledge and is something that I think separates the programming industry from every other industry out there.

If you’re thinking about going down the path to being a developer, find something you’re interested in and get started right away! Even if it stays as a hobby, theres always something to learn.

Sep

Working with Us

How does this whole thing work? Head to Hand. Brain to Phone. Lightbulb to Lightning Cable?

If you already have an idea of how building “apps” works then you’re most likely coming into the office with all your information ready and questions answered. However if you’re not really sure about how the idea gets from your head to the phone – we would like to give a little rundown of our process.

First. We discuss the idea.
There are two questions that need to be answered before any work can begin. First, what problem does this app solve? Secondly, who is the app for? If you don’t have solid and concise answers to these questions, you’re in for a whole lot of frustration and financial pain down the road. When you’re a month into development, and much too close to the project to remember where you started, you’ll love being able to go back and see if your new questions fit your initial value proposition. Yes? Great. No? Leave it. Knowing what you’re building prevents scope-bloat and allows for marketing/pitch success.

Second. We refine the idea.
Once we know what we’re building and for who, we sit down with our UX expert to refine features. You need a calendar app – great. Does the calendar need to send meeting invites? Do you need to see detailed listings or just high level? Do you want the views to be changeable (daily, weekly, monthly). Will the calendar send push notifications? What about having multiple calendars? As you can see requesting “a calendar” can have a lot of options.

We are here to show you what is ideal for your app and its users, what is possible, and what is cost efficient. When you say you want a house – is it this? or this?

During the ideation process we build wireframes. Wireframes are individual screen plans for all of the app’s features. The final wireframes allow us to give you a really strong idea of scope and timeline for development and serve as the app’s architectural plans. Without building wireframes we could guess at a feature list like “calendar, menus, list of cats” but it could easily fluctuate depending on what your interpretation of that feature really means (see the “houses” above).

Third. We design and test with real live users.
We take the wireframes and lay design on top. We will get a feel for the design on the project not only from who the targeted users are but also the brand and goals of the product. We do this in several ways – looking at competitors, apps the client likes, and making pinboards (yes, they’re useful for more things than your mom’s craft projects). We also place the design in a prototyping tool, Invision, where testers can click and explore. Post-design/pre-development is the best time to make sure what you’ve built works well with your users. You’d be surprised what you learn.

giphy

After the design is approved and flows are optimized based on user testing, the assets are exported and ready for development.

Fourth. We get to coding.
Our developers take the wireframes, designs, and interaction instructions and build “user stories”. These stories compose the scope of the project. “A user can tap a login button to view a login screen” or “A user can tap “support” to bring up a completed email” or “A user can view a loading animation”. These user stories are the meat of the project. If a feature is not clearly specified in a user story the developer will not know what to build. Or really – we can make assumptions. But we all know what happens when you assume….

Many times while coding, there are additional choices to be made (how should this baby be built under the hood?). With code being broken into smaller user stories a client can come in at any time and re-prioritize tasks, leave notes on current tasks, or adjust the plan without affecting the past work or current schedule.

Fifth. We test and deliver the code.
During development, when a set of user stories are finished (similar user stories are grouped into Epics – ie. “onboarding”, or “settings”) they are tested and reviewed by other crew members. If everything looks great, it is sent to the client. We generally like to send “builds” of code to the client at least every two weeks.

200

Steps Four and Five on repeat.
Code. Review. Test. Code. Adjust. Review. Test. Adjust. Code. Code. Code. Review. Test.

Sixth. We publish the app.
When everything is ready for a current version – we push it to the app store. That doesn’t mean it magically appears in a user’s hands. Apple and Android once again review your code and make sure it is in working order for the user. After their approval, it is in the store ready to be downloaded, promoted, and used by your adoring fans.

200

Jul

When does it make sense to hire an app developer?

People talk a lot about how to hire tech and where to find good talent but not a lot of people talk about whether or not you really need to hire.

You have a fledgling company – it is based in tech. Time to hire tech people right?

200

Actually, it depends.

Let’s let Wiley run the numbers for you:

Hiring a mobile developer costs at the very least $100k a year (salary + tax/insurance/perks/bonuses)
Hiring a development shop with a $100k budget would give you around 21 weeks of development
BUT. Most mobile apps take us between 4 to 10 weeks to build

What are you doing with that extra time (money)? What do you get for that cost?

Advantages of Hiring

With an in-house developer you get one set of eyes who knows the structure of the project closely. They’re with you for the long-haul (hopefully) and they sit right next to you (assuming they’re not remote). They have a set of best practices that will hopefully set you on a course for engineering greatness.

Advantages of Partnering

With a development shop you get multiple people – and as a result the ability to speed up your project timeline if needed. You get different areas of expertise. Need someone who does Android development? iOS development? Bluetooth Low Energy? A development shop has a team with a breadth of experience and can pull a person that matches what you need at the moment. You benefit from their deep reservoir of experience and industry knowledge. LunarLincoln even offers guarantees on certain contracts, so if a bug is found, it gets fixed at no extra charge (good luck getting your employees to work extra long hours to fix their mistakes).

On CTO Full Stack Ninja Unicorns

What if I just hire a bad-ass CTO who can do our development AND manage things? Experience, vision, and skill right? With this approach you’d be committing a percentage of their time to development, but the real question here will be efficiency. Has your CTO shipped hundreds of apps and updates to the App Stores, and do they know the tricks to get that right? Will they make the right decisions the first time or will they have to rewrite things several times to get it correct? Basically, how much time will your CTO have to spend learning to get to the level of efficiency that of a seasoned developer whose sole responsibility is building apps? Plus, doesn’t your CTO have better things to do with their time? Why not focus them on the things that they’re really good at?

There are always downsides to both

What if you make the wrong hire? What if your developer only knows one language (iOS) and needs time to get the other platform down (Android)? What if your developer is sick, on vacation, quits during crunch time?

What if your dev shop doesn’t communicate well? What if they secretly put some noob on my project and the tech debt is staggering? What if they blew the budget and we’re only halfway done?

It happens. Hiring is scary. Spending money is scary. Partnering is scary. But you can do it.

What does all this back and forth really mean? You’ve given me pros and cons but no assessment?

Can you just give me one of those sweet decision flow charts already?

Ok, ok, ok.

Hire an in-house dev if:

You know exactly what you need technically
You have the budget to hire the best (and know HOW to hire the best)
You’re going to need their specific skills long-term (beyond the initial push/development)

Hire an agency if:

You don’t know how to hire the best yet (we did it for you)
You have a limited budget runway
You need to get to market fast
Your project can benefit from a deep pool of technical skill
You may only need development for the initial push and then time to regroup

Hire a CTO/Dev if:

Don’t do this. Unless YOU are the CTO dev and then be prepared to be stretched really, really, thin.
Get a consultant, take someone out to coffee, you don’t need this until its time to growgrowgrow.

Apr

Working to Live not Living to Work

“Startup Life” – everyone knows this means long hours and intense work schedules right? It’s all about doing more with less, and if you’re not putting in more time than everyone else you’re clearly not cut out for startups right? Right?

A little known fact: LunarLincoln has a 35 hour work week.

We also let our crewmates work whatever hours they want to. Why? For so many reasons. Because we want to create a sustainable work environment for our crew. Because we know we get better quality work when our dev’s are fresh and in the proper mindset for the task at hand. Because sometimes you hit a wall and just need to take a break to clear your head. We don’t put in “Let’s check Reddit since I have 30 more minutes till 5pm” time, and we don’t put in “I’ve already worked 50 hours this week on this project but have to put in 10 more to push it across the finish line, who cares about code quality at this point. Get. It. Done.” time.

http://alifeofproductivity.com/number-of-hours-work-a-week-to-be-the-most-productive-35/

Graph courtesy of http://alifeofproductivity.com

We only require 32 hours because our crewmates are individuals who deserve to be husbanded and treasured. They aren’t expendable and they’re not interchangable. We aren’t a code factory, we’re a small shop of craftsmen. (Plus there is some science to this madness ^)

Do your work. Do it exceptionally well and be proud of what you’ve created. Then go home and enjoy your life. If that life is learning more about mobile app development or building your own apps, awesome. If it is going to concerts and throwing dinner parties, that’s awesome too. We want our team to take that time and recharge and refresh, and most importantly we want them to live their lives.

But wait, you said a 35 hour work week, what are those 3 extra hours?

We want 32 hours of client-billable work. The work that supplies the paycheck. But you know what not only helps our crew but the final client product too? The time to learn new things. Learn the best new techniques, programs, and languages so that we can be more efficient, effective, and on top of our game. Those three hours are for personal development, whether that is reading blogs, using some extra time to try a new thing, or going to an event in town. It’s important and nonnegotiable.

While there are many approaches tech companies take for “salaried” workers we feel that this equation works the best. “Startup Life” doesn’t have to equal epic burn out.

200a

For us, “working to live” makes for a happy balance and keeps us excited to build new things each and every day.

Apr

Native vs Web Apps

When building a software product for mobile, there comes a time early on when you must decide between building a native application or a responsive web app. When making such a decision, it’s very important to understand the implications of going one way or the other. A native app is typically more expensive to build, but the extended capabilities and high speed execution often makes it necessary or at least advantageous for certain products. Today we’ll explore a few benefits of building native apps to help make this decision easier for anyone setting out to build a new mobile product.

blog-42

Why go native?

Direct Hardware Access

Icons8 One huge advantages of natively built applications is they have direct access to many hardware features that web apps simply do not. While HTML5 has brought easy access to the camera and microphone with the <input> tag, these elements simply output a file and don’t give you access to the media in real-time. If you want to build fun camera filters or do any kind of signal processing, you’re much better off in the native realm.

While web apps have some access to media capturing hardware, they don’t have any access to some of the other sensors on the device. For example, native apps on iOS have full access to all HealthKit data (should you allow them) collected by the motion co-processor and other activity trackers, which are always working whether your app is running or not. Native apps can also use geofences and other location-based triggers to provide context-aware behavior and offline notifications, which can draw your user’s attention back to your app at opportunistic moments.

Blazing Fast Execution

200 (4) Native apps can work more efficiently because they run directly on the hardware, meaning there’s very little overhead to performing computation. This can make a huge difference when doing lots of graphical work or anything that is computationally expensive. While hardware-targeting makes applications less portable, it allows them to really take advantage of the processors they run on, giving you the high resolution and fluid graphics you see in native games and media apps today. Apple’s graphics library Metal is a great example of this, being designed specifically for the GPUs in Apple’s products to achieve maximum performance.

User Experience

There’s usually a clear difference in appearance and quality between native and web-based apps, as web apps lack the responsiveness and familiar UI elements of a native app. While web apps can certainly accomplish a lot, the extra layer of separation brought by running in a browser or web view rather than natively means the app can’t respond as quickly to things like touch events. This accounts for the slight lag you experience when interacting with the UI of web-based mobile apps, which amounts to a less-than-stellar user experience. Also, users may not pick up on custom UI controls from the web when they are used to a consistent experience from native apps on their platform, which can lead to usability problems. If the user feels like they’re swimming upstream to use your app, they probably won’t keep at it for long.

Offline Functionality

One clear limitation of web apps is the necessity to download them over the internet each time they are loaded. Since native apps are installed once and can store tons information on the device, they can provide all kinds of functionality without an internet connection. iOS apps can even preemptively load data before the user opens the app through silent push notifications that “wake up” the app to retrieve new data.

Even with an internet connection, the first few seconds of a web app experience often consist of spinners and sluggish stylesheets causing elements on the page to jump around as it loads. This requires a measure of patience from your user, which might be too much to ask from some users especially after navigating through a few pages. With user attention spans getting shorter and shorter, you need to capitalize on every second they spend in your app, creating value for them and not putting them on hold to download and render bloated web pages.

"We're getting really close to ready" – the false dream of hybrid apps pic.twitter.com/xyvXT3qNao

— Bill Morein (@wmorein) May 5, 2015

In short, while native certainly isn’t the right choice for everyone, there are a quite a few cases where it’s necessary or at least beneficial. It’s important to consider these implications not only for the current state of your product but also for it’s future, as it would be unfortunate to commit to a web-based platform only to have to rebuild later when you need native-only features. While historically writing native apps have meant coding for one platform at a time, there have been big developments in native, cross-platform solutions such as Xamarin, now backed by Microsoft, and React Native, brought to you by Facebook. These solutions, while still growing, hope to deliver the fully native experience without limiting you to a single platform which can greatly reduce the cost of certain projects.

Apr

Mobile Madness – The Championship

This is it, you guys. THE CHAMPIONSHIP. Who will be the ultimate winner of Mobile Madness 2016?!?

200

Swift vs Jake Wharton

[separator type=”” size=”” icon=”star”]

Swift

Swift has had a crazy, semantically satisfying ride to the finals in this tournament. It was picked in Round 1 over the world’s most used programming language, Java (*ahem* thanks fanboys *ahem*). In Round 2 it beat out it’s arch nemesis, the big, bad Objective-C. And then in a crazy match up that left even Apple fanboys wondering who would win, it stomped iOS. Finally, Swift beat out the juggernaut that is AWS to earn a spot in the finals!

We’ve covered Swift’s benefits and shortcomings fairly thoroughly in previous posts. To recap for you fair-weather fans:

“Swift is quite new on the scene, which only hit 1.0 in September, 2014. It has been acclaimed for it’s use of functional programming and value types which can help simplify problems in the minds of developers. With much to prove for general use outside of iOS and Mac apps, it’s support from the open source community as well as big players like IBM is driving adoption for the language at a rapid pace.”

[separator type=”” size=”” icon=”star”]

Jake Wharton

Aaaand on the other side we have the legendary Jake Wharton. In Round 1 Jake scored a win over UX giant Roman Nurik. Then he won the battle of the Jakes to advance over iOS indie Jake Marsh. He faced off with Swift contributer Erica Sadun and came out victorious to advance to the final 4. And somehow he beat out Steve Ballmer (!!!) to advance to the finals.

We’ve written a lot about Jake in our pervious posts, but for those not paying attention here’s a recap:

“Jake thrust himself into the spotlight with his incredibly famous open source Android libraries such as ActionBarSherlock and NineOldAndroids, as well as his contributions to Square’s massive catalogue of open source libraries such as Butterknife and Retrofit. He continues to deliver enlightening talks and presentations about Android and its continued evolution as a platform. ”

[separator type=”” size=”” icon=”star”]

Who will be the winner?!?

In a lot of ways, this matchup comes down to iOS fanboys vs Android fanboys. After all, those of us who grew up in the early days of Android development would have had a tough time without Jake’s timely and useful libraries. On the other hand, Swift has breathed some new life into iOS development and actually got us excited about a programming languages. So who will you pick to be the one to rule them all?