How easy is it developing an app for all platforms: Android, iOS & Web?

Up until now I have been using meteor entirely for the browser, and haven’t really looked too far into the device deployment options.

I have seen the tutorials and have build a demo iOS app and ran it on the simulator. It took some tinkering but I eventually got it working. Haven’t tried the Android version as I don’t have a device, but the steps involved seem similar enough.

Am I being too wishful, thinking that I can build my app for the web with a mobile friendly UI, and then simply meteor add-platform ios android. From there be able to deploy my server, and compile the mobile apps for the two device platforms?

I know that if I want to use some of the native features offered by the device SDKs that would need its own custom client code. In the last few weeks I have just seen people post issues with Cordova and how some things don’t work how you would expect etc…

What are some tips and advice from people that have already done it or are doing this right now?

2 Likes

Start with meteoric for your mobile code. It is very quick to pick up, though you’ll need to look through the examples as the documentation is a bit lacking right now. It’s being actively developed and is very meteorish in its implementation.

The downside to this is that you will end up writing a different webpage from your app unless you don’t mind the website looking like an app. But on the plus side you get a very native feel app (styled specifically for android and iOS differently) with one codebase. Then it really is as simple as adding the android platform.

4 Likes

Thanks @jchristman this is actually one of the things I tested out. That is pretty amazing that it can work like I said.

I would love to hear from some others with some tips and ideas.

I’m attempting to build a Cordova app for a client, and so far the only major thing I’ve bumped into is the persistent login thing I posted in the other thread (which may be a platform specific problem). Using meteoric as well for the UI. It has a few bugs, but gonna give this thing a fair go before falling back to native development. Overall it’s a lot easier than coding native apps, especially with implementing push notifications.

1 Like

Thanks for the response!

Cordova is nothing more than a packaged browser with no UI plus some hooks to take better advantage of the device, right??

How does routing work when you’ve built it as a native app, compared with a web app…?
Any <a href=""> links and JavaScript invoked routes just work like usual.

Yeah, pretty much, it’s just a webview.

Routing works the same. Your app has internal routes and all your resources are packaged up so they can be accessed normally.

Now what would be the difference between using something like ionic vs just using meteor and a css framework like materializecss and then bundling it up with cordova/phonegap?

Wouldnt the second option leave you with a nice desktop version as well, instead of having ionics “app” look on desktop?

ionic just provides a “more native feel” to your UI (and looks different on Android & iOS). In my case, the main meteor web app is one project, and my cordova client is a separate project as it has a different function to the web app (mainly push notifications). My cordova project shares the same server/ dir as my main app. (ln -s ~/dev/app/server ~/dev/app-cordova/server)

1 Like

Are you using any ionic on the web app?

No ionic on the web app. Mobile & web clients are separate.

1 Like

Well what else does ionic bring to the table? With the meteor+css framework+cordova combo, wouldnt that just build a native app with a webview? Basically a browser window with a launch screen right? Other than some basic UI components that would change from Android->iOS, what other advantages would ionic have? Do people really care much if their menu button is 3 dots vs 3 horizontal lines?

So you manage a separate set of client code for both?
Is that just because you want a completely different look on each?

How do you manage that, sounds like an extra layer of work to make sure things are working?
Also an extra whole client interface to test and update when the app changes.

@orbyt There’s other UX stuff, like for example you can swipe to open the side menu.

@cstrat yep, separate client code for both. Not because I just want a different look, but because the mobile app is only supposed to do push notifications. The app I’m working on is a sort of team organiser, and the mobile app is just a companion to deliver notifications to team members before games begin.

…like this? http://materializecss.com/mobile.html :sunglasses:

ur project sounds great btw gl.