Ask HN: Making a mobile app as a back-end developer?
My main area of expertise has been backend java development for years. I have a few mobile app ideas I have been designing the backend for a while. But since I have no frontend experience, I don't know how to proceed. Should I start learning, which will take large amount of time since there are plenty of platforms you need to publish, or should I outsource it somehow ? If outsourcing is the right answer, where to find people I can work with ? Please forgive my English.
109 comments
[ 4.4 ms ] story [ 181 ms ] threadDepending on the functionality needed for your app idea (and your skills), this might be a good path.
This was in the early 2010s.
The way to design widgets is pretty horrible but you get used to it.
My general advice is to pick a project that seems achievable fairly quickly and do your learning while trying to make that real. It’s much more motivating than learning for learning’s sake and only then actually making something.
If you want to learn and start with iOS, I'd advise doing the 100 Days of SwiftUI: https://www.hackingwithswift.com/100/swiftui
The great thing about this course is that you can do it alongside your work, because it's divided in chunks of 1 hour. My experience is that you can do it in the evening, even after a full day of work.
The framework is well designed and makes setting up the UI for native apps pretty easy with a lot less coding than I'm used to for other frameworks. I'd recommend looking into it if you don't care about cross platform (and I wouldn't personally care about that right away if you're getting your feet wet with mobile).
Swift is also a fun language to program in once you get the hang of it (and yet it's not too different from other languages, so it shouldn't be too hard to pick up coming from Java).
Although with previous Java experience Android might be easier for you to get into.
Flutter allegedly consumes about twice as much memory as a native app. So I guess it matters who the target audience is and what kind of device specification can be expected.
Disclaimer: I have never written a Flutter app and I'm not sure if the information I have found is still up-to-date.
Edit: What I have also found is that there are plans (or ongoing work) to port Flutter to Apple's Metal framework, which should cut memory usage by a lot on iOS.
Edit 2: Here's one of the benchmarks: https://thoughtbot.com/blog/examining-performance-difference...
Would be interesting to benchmark Flutter's memory use vs. the app that was never built because of the lack of time, steep learning curve, boredom, etc, to deliver both iOS and Android natively.
Coming from a web background, React Native made the most sense for me. Since I started using it a year ago, I absolutely love it. Great community with constant updates from Facebook, tons of articles/blogs/courses on how to learn it and there hasn't been a single feature Ive wanted to build but couldn't due to some lib restriction
You don't need to ever 'build' Dart unless you're going to be working on the language itself... and if you are, you might as well be a google employee and get paid for it.
Setup for Flutter development is just a few easy steps.
> We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful. Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings. Another example of this directly benefiting users is the addition of tabs in macOS Sierra. macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps. Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
[0] https://news.ycombinator.com/item?id=20612195
Unless you're writing an IDE, you're not going to lose users (you care about) over not supporting Emacs bindings.
People will put up with a lot of garbage if your product fills a need. And non-native UI is not even inherently garbage, just sub-optimal (and even that depends on the product)
Yeah, these aren’t great deals, but people who care enough try to switch to alternatives. And by using native UIs, you can mitigate your concerns about whether you implemented everything the user expects or not.
They had the opportunity to be promoted as app of the day by Apple, which would have been awesome for them.
Unfortunately the condition was to ship an apple watch integration. The sdk they were using did not support it.
The Facebook app is criticized everywhere, I can’t think of anyone who likes their app.
AFAIK AirBnB once used RN but moved to native development, and Twitter use native widgets.
Also, don’t forget that they have the resources to develop all of the expected features of native widgets, for example Accessibility. The OP probably doesn’t.
And, this is all talking about RN which is actually half native since they use native widgets; Flutter is much worse than this because they draw their own widgets.
You're talking out of both sides. The OP is obviously limited on resources. That's the exact reason flutter is a good option, he gets an app that works on iOS and Android in one codebase using a modern language. Going native requires 2 distinct code bases, which itself requires learning all the specific quirks and features of each platform. Android adapters and fragments, XML layout, distinct libraries for simple Http calls, object serializers, etc, etc. The only downside you can point to is "its not native" and guess what, see above, users don't really care.
That seems to live up with what was said further up the thread:
> People will put up with a lot of garbage if your product fills a need. And non-native UI is not even inherently garbage, just sub-optimal (and even that depends on the product)
If you’re making a product that other people use, I would caution you against putting their needs on the back burner. It’s very often the case that what’s easier for the developer ends up making a worse product for the people that have to use it.
> Unless you're writing an IDE, you're not going to lose users (you care about) over not supporting Emacs bindings.
No, the whole point of this feature is that it works outside of an IDE. I don’t even use Emacs and these shortcuts are so ingrained in me that I ended up setting up custom shortcuts to emulate this in the places that wouldn’t support it (where possible, of course…).
Unless you mean some of their needs.
In which case yes, that's my point. If you want a successful product, prioritizing features is very important, and in most contexts, filling your "core need" is going to add a lot more value than a native UI does.
>I don’t even use Emacs and these shortcuts are so ingrained in me that I ended up setting up custom shortcuts to emulate this in the places that wouldn’t support it (where possible, of course…).
Unless your tool is for a space where a lot of users are going to say stuff like this is a major detractor for your new product (...like an IDE or other developer tool) you're much better off just making your product and validating it.
-
When you're making a new product, and bootstrapping it like OP describes, your currency is time.
Time isn't just money, it's a changing market, it's your own motivation coming and going, your overall situation can change and make working on it untenable.
The less time you spend fighting a lack of knowledge the better.
A working MVP in Xamarin.Forms in a few weeks > months spent killing the moment for your idea and learning enough iOS and Android to have the base knowledge for a middle of the road native app, is true much more often than people like to admit.
Maybe you can live with them, maybe not, it depends a lot on the usecase.
That jives well with our product, but we do also need a mobile app to interface with the product. Flutter has been great in this regard. Dart and the declarative UX framework are very grokkable for backend folks.
The UI/UX is definitely good enough. Our app feels native, is snappy enough to get the job done, and looks way better than the native Android app we were trying to build before. Even if we were to have to go fully native down the road, Flutter is just the right tool for the job of getting us off the ground.
For a small team, there's just no way we could build both an iOS and Android app separately, on top of hardware, firmware, and a backend. It would kill us before we ever even launched.
n.b. to you.
I've also built a small flutter app where everything runs snappy and it more than solved the needs with a minimal development time and number of lines of code.
If the goal is to build a project as a hobby and (maybe) make money from it, best to learn any of the cross platform tools for mobile apps, here are some popular ones: https://hackernoon.com/9-popular-cross-platform-tools-for-ap...
Best of luck!
Surely you mean disk space, not RAM?
I'm sure you meant disk space instead of RAM perhaps? I think it would be overkill to obtain a Mac with 256 GB or 1 TB of RAM just to create iOS Apps. ;)
Even though OP said they are a Java developer, I would strongly urge going with Kotlin for Android at this point. Kotlin replaced Java as the default language for native Android development in 2017, and new code samples are being written in Kotlin. At the very least, start with Java, and ease your way into Kotlin, since it's 100% interoperable with Java. Aside from being the default Android langauge, Kotlin has many other benefits.
Benefit is that you can develop on Windows, Mac, or Linux, won't have to buy an iDevice or two, or a new machine.
Only once you’d like to publish your app on the App Store.
I did not realize this. Sad :(
You could maybe hire a contractor or something to help make the UI better if needed. Personally, I wouldn't bother unless your app is published and bringing in money, and you can make a business case that spending $X on making it better will bring $Y more revenue. That would give you an idea of what's a good amount to spend. I wouldn't worry about any of that yet though.
On mobile we work with pretty high-level abstractions, so if you did this yourself, most of the new stuff to you would be the frameworks like UIKit or Core Data (at least on iOS).
Edit: Ray Wenderlich and objc.io are my go-to learning resources for iOS stuff
He has books, but they cost a fair bit (around $100/book iirc), and they're not included in the subscription I think, unless I'm missing something.
On the plus side, though, tooling for Xamarin is a lot nicer. VS is definitely a first-class citizen, and being able to launch on a remote iOS device/simulator from inside VS is a definite advantage.
Personally, I'd go with Flutter, but it's still a lot to learn...
https://developer.apple.com/tutorials/swiftui/
React native or flutter seems more long term ( although i must say i find them also problematic in some regards ).
Knowing the OP works with java, i would also recommend another option going with kotlin and do android only, as it i by far the largest market, and you will have a far lesser risk to get banned from the store for dubious reasons.
Edit : reading other comments i realize the cordova / ionic option also makes perfect sense on today’s hardware. Just make sure you understand the limitations and try a few apps made with that tech from the store first.
From what I read here and there, that's a half-baked myth in a number of ways. Android users often lag behind the latest Android version, lacking access to the latest features. In terms of revenue as well, Android apps don't seem to be ahead of their iOS counterparts. Someone with experience in publishing for both ecosystems may be able to correct/corroborate this.
SwiftUI targets iOS, macOS, tvOS and watchOS, all counting for over a billion users combined. That's a substantial market, even when considering that it's limited to the latest version of each OS. And it's obvious that Apple's focus will be on SwiftUI going forward.
But by that metric android is 2.5 billions.
now depending on your business, you may indeed want to target ios users as well, but gone are the days of « ios first, then maybe android later » (except maybe for tablets, where the ipad reigns alone).
As for swiftui, apple does indeed seems to be pushing forward with the tech, but at this point i don’t think it matters much anymore. Videogames are developped with cross platform tools ( because 3d) , form-based apps are developed with cross platforms tools (because ui performance is now good enough). All we’re left with are non-gaming interactive apps where you still need maximum responsiveness. And even in this case you’re often better just developping only that screen natively and leave the rest cross platform.
You'll bump into a couple of things which require workarounds. For instance, you can only stylize the navigationbar if it's in normal mode, not if it's in the nice large title mode, and you'll have to use the UIAppearance API for that.
I'm also seeing lots of people calling things "bugs" but they actually just misunderstood the new layout system. I haven't seen showstopper bugs. Frustration is, however, unavoidable because it's a learning process.
I needed to build front-ends and went the JS way. Vue.js and a framework (bootstrap vue for instance) and you are good to go.
With PWA you can make such an app very similar to a native one.
In terms of effort, for an amateur Python dev like myself, it took maybe a weekend to understand how this works, and then more time to get the details.
A lot of Android is not front end. SQLite databases, models, maybe use cases, JUnit unit tests etc. You know how to do a DAO to MySQL, Oracle or Sqlite? You know how to do a JUnit unit test of a data structure? That part will be easier then.
Keep UI simple - one Activity, Navigation and Fragments. Use a ConstraintLayout and simple views like TextViews. Use a popular, simple image library.
Much of Android work is not UI work. Keep the UI simple initially.
I'd suggest OP download Android Studio. It's based on IltelliJ, so there's a good chance OP will feel right at home.
or
the ionic.io framework
[1] https://vue-native.io/