Mobile Development

... ...
Now Offering NativeScript Apps!

There's An App For That..

And it could be yours! I build web, hybrid, and NativeScript mobile apps.

With the diverse range of mobile app types, there's a style of app to fit your budget. If I've written other software for you in the past, ask me how it can be tied into your mobile app!

What I Offer

I offer both web and hybrid mobile app development. In addition to this, I've been working with a framework called NativeScript. This framework allows me to create apps that are a mix between hybrid and native mobile apps, but the end result is much more on the native side. It does not require two sets of code and is written in an XML style language.

The finished product produces beautiful looking apps that strongly resemble native mobile apps, so I've grown to quickly love NativeScript. I'm pretty sure you will, too.

Pros & Cons Between Mobile App Types

Mobile web apps are the easiest of the 3 types in a variety of ways. First, if done properly, only 1 set of code is ever needed for your website and your app. This means maintenance costs are decreased because updates only need to occur in one place. Your website will change in appearance between various devices, much like what this website does. Since web apps are web-based, this means there is no app store to download the app from. You just go to the website.
These are not true apps in the mobile sense — they can't take advantage of any hardware on your mobile device such as accessing your device's calendar, sending push notifications, gps, accelerometer, and more. There's a few things you can "fake" such as the camera (WebRTC is good for this) but if you need to rely on the device to some extent, this is not a good way to do it. There are also some slight variations in payment processing code due to potentials security risks in something called the webview. For this reason such as this, IOS is additionally sunsetting UIWebView and will not be allowing any new apps to use this particular view in the upcoming months.
This is a step up from web apps. Web code is compiled into .apk and .ipa files (for android and ios, respectively) and uploaded to the app stores so others can download your app. There are also ways to access the actual mobile device components, such as calendar, camera, battery, gps, and more through the use of things like Cordova plugins (this is where open source becomes very useful). Hybrid apps get you in the door with your own downloadable app.
This is where your project can start to become a little pricey. If any updates are needed to your app you have to make the update in code, recompile it, and then resubmit to the relevant app store(s). All apps that get published to any app store, no matter android or ios, will be reviewed by their tech teams first which causes delays in publication. Hybrid apps also start to introduce something called "split logic". Android and IOS are not the same beast, and therefore, forces your code to have to work in multiple ways — from varying device limitations to the visual appearance of your app. You are also at the mercy of the limitations of any plugin used in the app. For most basic needs, however, this is a non-issue. This only really becomes a pain if you need to do something more complex, like syncing information to the device calendar.
Native mobile apps are the purest of them all. The app itself is very smooth — it performs and scrolls much better than a hybrid app, and graphics are very sharp. Transitions between pages are quicker and everything works naturally inside the app, such as the back button.
This type of app is the most expensive to build. True native apps are written in Java for android, and Objective C, or Swift for ios. This can mean two sets of code to maintain and often times, that also means two different developers.