12 ms·

Ask HN: What do you regret you didn't know when programming for iOS or Android?

237 points by toron123 7y ago

What do you regret you didn't know when started programming for iOS or Android?

maxaf 7y ago
I should’ve known that it’s turtles all the way down. Considering how many years I’ve sunk into programming for other platforms, this shouldn’t have come as a surprise, but I got suckered into believing that mobile computing platforms represented a significant enough paradigm shift to allow for starting with a cleaner slate. Not true! Having gotten into iOS development over the past couple of years, I’ve come to realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform. For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple’s latest and greatest programming paradigms. Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
- ken 7y ago
  SwiftUI isn’t UIKit-specific. Display Postscript hasn’t existed since the OS was called NeXT, 20+ years ago, and was never on any iDevice. Cocoa is an alias for AppKit + CoreData, and iOS uses CocoaTouch instead.
  - dahart 7y ago
    You’re right, yet this doesn’t directly address what parent said, in fact it’s somewhat agreeing with the point, that there’s a ton of influence left behind by these things, even though they are not there anymore.
  - mattl 7y ago
    Display PostScript is in Apple Mac OS X Server 1.0 and then abandoned in favor of Quartz and PDF.
- erokar 7y ago
  > Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed. I guess that's what Flutter is doing (for both iOS and Android).
  - chooseaname 7y ago
    > I guess that's what Flutter is doing (for both iOS and Android). How does it do this as opposed to adding yet one more layer? Does it somehow get beneath all the cruft mentioned?
    - Signez 7y ago
      Flutter took the approach of treating the screen as a blank canvas. Everything is drawn using Skia primitives, exposed as Dart libraries. It has some downsides – they had to expose a lot of accessibility features on top of that using platform APIs – but it's quite nice when you are a developer, as you can Cmd-click on anything to learn how it is drawn, and use the same tools to build your own widgets if you need.
    - lhoff 7y ago
      Afaik Flutter is basically a Game Engine. Its not using the build in UI Toolkit instead rendering everything itself and just mimics the look of the native UI. I'm not completely sure about it, i just now it from listening to some talks.
    - wolf550e 7y ago
      Yes. It's not using any native UI widgets or UI code, but drawing everything itself using the lowest level API it can get, which I guess on iOS is Metal (and something for input). This means that the look and feel and the behavior and accessibility features will not match those of other apps (which do use the native toolkits), or the Flutter team will have to do a lot of reverse engineering and re-implementation to match that on each platform.
      - kitsunesoba 7y ago
- gumby 7y ago
  I consider this a feature: the older code has known behaviour, while a from-scratch implementation would have been a minefield of unknown bugs
  - maxaf 7y ago
    I’m not buying your reasoning. Try putting a WKWebView into a SwiftUI view. This kind of thing is all sorts of messed up when multiple rendering systems - two of them declarative (SwiftUI and HTML) - collide in a single view. I’m sure someone’s going to call this a corner case, but useful and interesting apps that push the boundaries of the feasible are all composed of such “corner cases”. And hey, I’m not even doing anything outlandish: just trying to show some HTML.
    - gumby 7y ago
      I sympathize with your position and have had similar problems in the past. There’s no magic option. But typically the combination of a completely new API and implementation is very difficult for both implementors and users.
- jayd16 7y ago
  I think certain paradigms were completely shifted compared to the PC space. -Revamped permissions -App packaging/name spacing/consistent installation -IPC was redesigned as asynchronous Intent blobs on Android -Urls becoming first class citizens at the OS level -More consistent background app apis (and eventually better ways to track them) I could come up with more but I think there's actually a very big difference. But yes, its all built on top of older Java and obj-c libs.
- simonh 7y ago
  > Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed. Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage. Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear. So legacy is a thing for a reason, taking one opportunity very often means giving up another.
- deleted 7y ago
  [deleted]
ddxxdd 7y ago
I regret not knowing about cross-platform development such as Flutter and ReactOS. I also regret not buying a book explaining all the concepts in as simple a manner as possible. As a semi-amateur programmer, I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile.
- freehunter 7y ago
  Agreed. This absolutely kills me when people say “just read the documentation” or “the documentation is very good” as a reason why they don’t produce examples or templates or starter kits. Not all of us are CS majors or programmers in large teams or with decades of experience to fall back on. Just reading the documentation isn’t enough to get me into a new framework or language. I need to see practical examples. For mobile development, this is why Expo was so crucial for me to understand how React Native works.
  - afarrell 7y ago
    > I need to see practical examples And I need to see diagrams of mental models, though practical examples help solidify that. So one challenge with writing documentation is knowing what your audience needs. A better taxonomy of documentation would help solve this. For now, here is one I like based on https://www.divio.com/blog/documentation/ https://www.divio.com/blog/documentation/ - Tutorial: A walk through how to learn the basics as you build something. - Explanation: Showing the mental model of something - Guide: A walk through how to solve a specific problem - Reference: A comprehensive* listing of the API capabilities and how they are used. ------- If anyone knows of some good tutorials or explanations of mobile programming with React, I'd be grateful for recommendations.
  - tonyedgecombe 7y ago
    Apple seems to be particularly bad for this, I was going through some of their videos recently and everything assumed prior knowledge. It's the same for much of the documentation. As much as I criticise Microsoft at least they have stuff like this: https://docs.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows https://docs.microsoft.com/en-us/windows/win32/learnwin32/le...
rowathray 7y ago
On the iOS side, I regret not knowing how horrible Xcode is and how horrible Apple's documentation is. On the Android side, I regret not realizing that no matter what kind of slick new well documented APIs Google releases we will all be writing code for Android 4.4 for the rest of our lives. Also, I wish I knew mobile developers are some of the lowest paid developers other than game industry peons.
- FeistyOtter 7y ago
  I have recently looked at surveys in my country and mobile developers are one of the most paid programmers out there, especially the ones experienced with Swift. What does cause the low pay in your country? Logically the sector is ever expanding and there is always demand for hires with any experience.
  - deleted 7y ago
    [deleted]
- unnouinceput 7y ago
  this applies to web developers as well. too many devs on both web and mobile, so salaries are lower then rest of IT technologies. usually a web/mobile dev needs to know a lot more to make it on the same par, at which point you can argue is a full stack one anyway.
- alkibiades 7y ago
  as a mobile dev at the FANG companies, were paid the same as other engineers. in fact, some are paid more because of the smaller talent pool
- vlozko 7y ago
  > Also, I wish I knew mobile developers are some of the lowest paid developers other than game industry peons. I wish I can tell you you were wrong here but I only have anecdotal evidence. Maybe you’re stuck in a company that’s taking advantage of you with a low salary?
- blackrock 7y ago
idrios 7y ago
I got pretty good at Android development and made a few apps that don't have many downloads but I'm still proud of and wanted to share with my friends and family. I regret that all of my friends and family have iPhones.
mikece 7y ago
I regret thinking that Xamarin was a good idea.
- garren 7y ago
  Amen. Management at a company I worked as were convinced that Xamarin was One True Path for mobile development. They were sold the idea that a Windows dev could instantly be productive in Xamarin without needing to understand the underlying platforms significantly. To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.
  - pbourke 7y ago
    > but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project. What would you go with now?
    - mikece 7y ago
      Ionic. HTML, JavaScript, and CSS work on (darn near) everything.
- ParanoidShroom 7y ago
  haha been there, should have left for a different company with our cto thinking xamarin was the best.
pjmlp 7y ago
The years it took to realize how under-resourced the NDK team is, bothering to create my own NDK wrappers to work around the NDK bindings and forced JNI calls, manually dealing with dependencies across NDK projects. In retrospect, it would have been easier to just rewrite the whole thing in Android Java. Basically, how little Google cares for game related development workflows on Android. It just took them 10 years to acknowledge this, go figure. https://android-developers.googleblog.com/2019/12/android-game-sdk.html https://android-developers.googleblog.com/2019/12/android-ga...
karmakaze 7y ago
I can't really say I regret the path I've taken since had I not taken it, I wouldn't be able to form sound evaluations. I'd always sought out cross-platform development tools first on servers, then desktop, and mobile. Flutter/Dart comes closest at the moment but game engines might also work for certain apps. I'm glad I never bought into React-Native the worst of worlds. It's rare for an app to require native widgets and having to deal with two different sets and their idiosyncrasies isn't solving the problem.
trangon 7y ago
MVC, the way it’s implemented in UIKit, leads to code that is very difficult to test, mixes business logic and view layout and navigation, and leads to massive view controllers. You have to be very careful to avoid it.
wiradikusuma 7y ago
That JavaScript (and prior to that, Java) would work for mobile, one platform to rule them all. Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.
- la_fayette 7y ago
  I can only agree with that. If you build a web app within a we browser you can use whatever payment method you want and the platforms don't take 20% for every transaction...
datavirtue 7y ago
Xamaron Forms
la_fayette 7y ago
That mobile web apps aka PWAs are a perfect fit for classical data-driven applications. The return on investment for 2 native apps vs. a PWA is far...
- izacus 7y ago
  You're not allowed to use full PWA capabilities on iOS though right?
  - la_fayette 7y ago
    https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7 https://medium.com/@firt/progressive-web-apps-on-ios-are-her... One can always build a hybrid app from a pwa...
McDev 7y ago
I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly. Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this. Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs. Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier. I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually. [0]. https://developer.android.com/topic/performance/graphics/load-bitmap https://developer.android.com/topic/performance/graphics/loa... [1]. https://developer.android.com/training/camerax https://developer.android.com/training/camerax [2]. https://square.github.io/retrofit/ https://square.github.io/retrofit/ [3]. https://github.com/android/architecture-samples https://github.com/android/architecture-samples
- applecrazy 7y ago
  Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.
  - mdocherty 7y ago
    I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.
fit2rule 7y ago
That Apple and Google would move the goalposts so often, and with such vigor, that it'd result in classes of programmers who do nothing BUT support the mobile platform for development. It has been a nightmare of keeping up with the majors, just to be able to enter their carefully curated arena. Nowadays when I build an App, I do Linux/Mac/Windows first, and the iOS/Android release, next. Fortunately there is a vast industry out there for toolkits and frameworks for solving The Platform Problem™ which has been shoved down our throats by a ravenous corporate culture which is hell-bent on ensuring that they own the computing platforms of the future.
- rowathray 7y ago
  What, you don't look forward to WWDC to find out what syntax got arbitrarily changed with no explanation?
VLM 7y ago
For android, get good at handling null everywhere in everything checking all the time now, or learn it the hard way later. You'll be spending lots of time tracking down "wait, how could that have ever possibly returned a null?" Ditto async and observer and livedata type stuff. Never move data between things any way other than async. MVVM and all that, with caching repositories and stuff. Architecture changes fast enough that you have to be careful not to waste time and effort supporting some ancient version and NIH writing your own implementations of stuff that's newly added in current versions. Yet if you try to ship using cool alpha quality features, that's a whole different headache. For extra fun you can end up with both problems at the same time in different parts of the app.
neeloor2004 7y ago
I invested lot of years on Android because it is, promoted as open source etc ... but currently it is just their advertising platform, complete control of it developer (removing developer accounts, blocking apps and devices ) and full monopoly !!
self_awareness 7y ago
I regret not knowing that Android API is awful. Then I regret looking into Nativescript, because it was pretty buggy. Then I regret not knowing about Flutter earlier. THEN I regret not knowing that Flutter is pretty buggy as well. Next step is me trying to learn other frameworks, like Cordova or React Native. I wonder what my regrets will be.
- alkibiades 7y ago
  all software is buggy
- sansnomme 7y ago
  If you want an idea of how good PWAs can get check out Pinafore: https://github.com/nolanlawson/pinafore https://github.com/nolanlawson/pinafore Runs better than most native apps.
- stevewodil 7y ago
  Flutter is quite good, what were some of the issues you experienced? The one PITA for me is state management, but once you understand how to solve that using BLoC or Providers then it should be relatively usable
  - self_awareness 7y ago
    Well since you ask: Flutter is good, but it's also buggy. 1. Problem with Cupertino theme on Android - https://github.com/flutter/flutter/issues/42988#issuecomment-574399565 https://github.com/flutter/flutter/issues/42988#issuecomment... -- only point 1 from this post matters, because point 2 was resolved by a helpful person below the post. But point 1 is still unresolved, and it looks bad. 2. Flutter runtime simply crashes on some mobile phones when loading the app. I've released an app on old SDK, and with every update of some minor thing + SDK I'm getting reports about new crashes from people who rated the app 5 starts on older SDKs, because it was working for them earlier. I've tried to report it: https://github.com/flutter/flutter/issues/43240 https://github.com/flutter/flutter/issues/43240 but my issue was grouped with some unrelated problem, and my questions were ignored. 3. I think the x86 codegen in Flutter is sometimes buggy. I've used a ZIP compressor/decompressor library written in pure Dart and it sometimes crashed in random location after using the library. I've tried to debug it but there was no pattern for the crash. The crash also was happening on the system level (SIGSEGV) instead of simply throwing an exception that would be catchable by Dart. When testing on the mobile phone, so when ARM codegen was used, I've observed no crashes and no problems when using the archive library. 4. Google AdMob has poor support for Flutter. The official AdMob lib doesn't support native ads, and is incompatible with widgets that draw an always-on-top layer, like Drawers or Action Buttons at the bottom right corner of the screen. It IS possible to finally work out the solution by using some thirdparty library which uses AdMob in a hacky way, but I would expect something better for one of the most crucial Google services like AdMob. 5. Until recently there was no support of Cupertino theme's i18n. I had to manually translate all texts of Cupertino theme to a different language (like 'copy', 'paste', etc). I've released two apps in Flutter but I'm afraid to update them, because something always breaks after update.
tomerbd 7y ago
flutter.
dfansteel 7y ago
Don’t underestimate the value of build tools. Just because you know Xcode and Swift or Android Studio and Kotlin (or their antecedent languages) are you done. Finally having a senior dev who knows what he’s talking about has done more for me in the past two years than the previous 8 of reading blog posts and hacking. He’s shown me the real value of build scripts. Today even my personal iOS projects are dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up but I can prove that my code works.
- ismail-khan 7y ago
  Would you mind elaborating on how build scripts helped you (what problem did you solve?) and sharing learning resources?
- ronsor 7y ago
  >...dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up... Can you elaborate on this? It just sounds like you have unnecessary complexity.
- Lich 7y ago
  Can you explain more? I'd like to learn more about this.
  - deleted 7y ago
    [deleted]
mobiledev2014 7y ago
It depends somewhat on why you ask. A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don’t plan to maintain long term, I’ll give them that. I know it’s cheesy but my only regret is I didn’t go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you’re early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it’s best to keep a healthy distance with things that only support the newest OS. For instance I wouldn’t build an app in SwiftUI yet but I follow it like a hawk because it’s likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must-know this decade. Mobile dev is so rewarding! Every developer should at least dip their toes in.
- MarvelousWololo 7y ago
  As a front end dev I’ve been thinking about it for so long but honestly I don’t know what I should build or study first.
  - mobiledev2014 7y ago
    It’s always best to work on something you’ll actually use. Maybe think about an app you already use but want to improve or simplify (a to-do list without the frills for instance). As far as learning, I think this Stanford course is the best way (though not for those who aren’t absolute beginners to programming). I notice it hasn’t been updated lately but it should be current enough https://www.youtube.com/watch?v=TZL5AmwuwlA https://www.youtube.com/watch?v=TZL5AmwuwlA
kitsunesoba 7y ago
That developing for Android isn’t even as half as smooth as developing for iOS. Yes, with iOS you’re using Xcode and have to set up provisioning for your dev device and all that, but once you’ve done that you’re mostly on your way. UIKit, while not the shiniest thing out there, is quite competent and functional — you can easily write world class apps with it while keeping third party libraries to a minimum. On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness. If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I’m not holding my breath.
- mst 7y ago
  > You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"
  - mntmoss 7y ago
    The best-case end result of this instability, of course, is the "double interface" - an interface abstraction on top that talks in terms of the domain problem, and then a second layer to convert the lower level interfaces into that abstraction. Unfortunately GUI is particularly fiddly and difficult to write the double interface for, since you get a "thousand words is one picture" problem: it doesn't reduce well to text.
vbsteven 7y ago
I regret it took me 5 years of mobile development (both platforms) to realize I really don’t like writing GUI code. I switched to backend and infrastructure work and I’ve been a lot happier since.
luxuryballs 7y ago
I built an iOS game using Sprite Kit and had to hack together support for multiple screen sizes later which was kind of a pain. Likewise they make you provide an app icon of like 25 different sizes. Have not done standard UI work yet but unless you use a “reactive” set of layouts I can only imagine the pain.
- m3kw9 7y ago
  Yeah if you plan the development around different screen sizes in beginning would be best, otherwise architectural changes will prob be needed unless like you side to hack it
aquabeagle 7y ago
I wish I would have not fought the tools so much. I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap). Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.
- vlozko 7y ago
  Code-only purists are still prominent in the iOS community. Yeah, there’s definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.
  - rimliu 7y ago
    I actually went the other way. With autolayout is just easier (for me), to do UIs in code. Especially because IB does not offer 100% of what UIKit has. I don't hate IB, it just become less relevant to me. Storyboards on the other hand… Never thought well about them.
  - dep_b 7y ago
    I’m not against IB but the lack of stuff like constants is really difficult when a customer demands “same app, different skin”. SwiftUI seems to fix this.
  - cloudwalking 7y ago
    IB files are essentially impossible to code review.
    - m3kw9 7y ago
      If you read the storyboard diffs the layout code is human readable, just need to get used to it. Although there is no docs
allo37 7y ago
On Android, that there hasn't been much love for C/C++ and the NDK is full of interesting pitfalls: Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense. Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense. The camera was a party too, added a listener for Camera session events and the app crashed. Yay.
- georgemcbay 7y ago
  The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then. All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app. This is kind of a theme in Android (or was... my experience is slightly out of date right now). As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression. Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.
  - pjmlp 7y ago
    It still is the same theme. For Vulkan and real time audio they expect you to checkout GitHub repos and compile from scratch, instead of having the tooling as part of the NDK. Likewise after 10 years they still expect everyone to manually write JNI bindings, instead of providing another productive way for language interop.
  - allo37 7y ago
    Well, glad to hear it's consistent at least :) Good news is we got a handle on all the little issues and now our code runs well on a wide selection of devices, but yeah, next time around I'd find a library that handles all the gory details. I find image manipulation works pretty well, though I've only been doing Android dev for 2 years so maybe it's improved. Or I just haven't done anything 'fun' yet...
hyko 7y ago
Example code is invariably dross from an architectural point of view. Unit tests are still valuable in a mobile environment. Most good apps are simple. Simplicity is not easy. Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It’s impossible to predict which category an aspect belongs to ahead of time. There are times to embrace the approach taken by a platform, and times to distance yourself from it. Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys. The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.
peterdekr 7y ago
I develop for Android since 2011. Since 2016 I also do more iOS. I mostly regret not looking into new developments faster. Things like Kotlin and Architecture Components. They are great, so at least experiment a bit with them to see what all the fuzz is about. Try to keep up! Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth. I also regret everything about Objective C ;)
usrusr 7y ago
On Android: being paranoid about multithreading in all the wrong places before I stopped worrying and love the main thread. Move actual work off thread whenever possible, but never try to integrate off threat memory access by hand using synchronized and friends, just enqueue your final result plumbing on the main looper. Be paranoid about multithreading in the right places, particularly when you hand a callback to some black box. A callback that checks the thread it's running on to enqueue itself on main if necessary might become a familiar pattern. You might start to hate all callback methods that don't return void.
smallstepforman 7y ago
If you built it, they wont come. Without marketing, the odds of your customers discovering the app (amongst a sea of garbage) are insanely low. I tried a Tennis app in 2009 and even back then it was competing with hundreds of other apps, now its mist likely 10’s of thousands. Heart breaking.
- ronyfadel 7y ago
  Sometimes if you build it, they will come. I launched a music app in 2012 (student project), and over its lifetime (6 years), I had 95k downloads and 7 million sessions on the app.
  - m3kw9 7y ago
    Some apps have very low viral aspects like biz apps or Utils, also some standalone single player games. They will be at the bottom of a search result of 100s when first released. Quite demoralizing
- mantap 7y ago
  Word of mouth marketing can be strong. For example I have purchased many apps because of a recommendation IRL, mostly music-focused (musicians love to talk about their kit). The point is to make something truly excellent, and if possible, conspicuous.
sehugg 7y ago
I started with iOS in 2009. I wish I hadn't used Core Data, and made the decision to store lots of large binary blobs in it. Changing the schema became impossible, because the migration process often crashed or ran out of disk space in production. That, coupled with lots of Core Data crashes that persist (pun intended) to this day. It may have been easier to just use SQLite directly. My decision to use NSThread for worker threads wasn't optimal either, but there weren't many async options in 2009 (Remember ASIHTTPRequest?)
conductr 7y ago
The whole damn thing. I’m self taught web developer, server management, backend stuff. I love a Rest over HTTP API. X Code and all the sims do not jive with my brain. Swift helped a bit. But only ever able to build a bouncing ball game. The process of launching on an app store alone seems insane. I started by FTP and Perl then PHP. I pay people to write code these days.
jamil7 7y ago
To get into mobile sooner. I was tired of the web and burned out needed something different. I’m getting way more work and enjoying myself a lot more. I hope to have a long career programming so maybe I’ll change platforms again one day.
winrid 7y ago
How hard it would be to Port.
ngcc_hk 7y ago
That you need a singleton pattern to ease the gps refresh problem. Totally rewrite the program before submit to Apple store.
debt 7y ago
The xcodebuild command line tool is insanely powerful. The one provided by vanilla Xcode is awful.
ryandrake 7y ago
If you think you will ever be cross platform, do yourself a favor and write as much of the business logic as you can in C++ or C. The platform-specific piece should be small and “just enough to make the platform happy”. Do everything else portably from the start.
Groxx 7y ago
The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets): Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things. It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your core logic is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores. It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.
- rmdashrfstar 7y ago
  Related to this is “clean architecture”. Your code should not be dependent on a feature-laden framework. You should focus on writing your business domain and rules, then separately orchestrate your domain, and connect the UI and other external frameworks as interfaces to the lower, or more generic, levels of your application. This is a general software design principle that allows for your UI to be free to change without affecting your core logic and rules, while also making all of your code more unit testable.
- richard78459 7y ago
  With React hooks or android component life cycle its hard separate the framework and logic. How do you do it ? Any recommended books or other resources ?
  - Groxx 7y ago
    React's behavioral features are relatively difficult, I'll grant, but it's entirely possible to use it as a relatively dumb "render X efficiently for me" target. If you're using hooks heavily, you're deeply entangling your code with the framework - that's your choice, but yeah, it comes with consequences as well as benefits. Android lifecycles are probably the main target of my comment tbh. They're abysmally complex and make any kind of state management incredibly error-prone. As a tradeoff for that complexity and losing a lot of control, if (and only if) you go all-in on them, you get decent state reviving after process death, which can do really slick things like "app crashed" -> it just appears to go back one screen. Instead, you can write your app as e.g. an in-memory singleton somewhere. You can even do that in a different thread if you want, leaving your UI impossibly smooth (at increased risk of "tap x" -> "nothing happens"). Design your own lifecycle that makes sense for your app (which probably looks very little like the Android lifecycle, especially when you throw in fragments...) and trigger/wait on the external world of the Android framework as needed. Odds are pretty good that you'll take multiple things from Android and combine them into one in yours, and potentially vise versa (e.g. multiple actions from your app become view updates in a single activity, rather than multiple activities. or do everything in one activity, it's often far better performance anyway, and much easier to control in fine-grained ways. importantly, your core logic doesn't care, unlike if you put that logic in the activities).
sshb 7y ago
On iOS: • Interface builder(especially Storyboards) is inferior to using UIKit straight from code • Coordinator pattern, which lets you split logic and view controllers. https://www.hackingwithswift.com/articles/71/how-to-use-the-coordinator-pattern-in-ios-apps https://www.hackingwithswift.com/articles/71/how-to-use-the-...
balladeer 7y ago
I wish I had realised that Android app development ecosystem (the dev tools, API, documentation, gradle, dependency management etc) is a shit show and is going to remain a shit show and I should have moved to backend early in my career. Now companies are very reluctant about it.
- Aduket 7y ago
  reluctant about what? backend developers?
jrs95 7y ago
React Native isn’t nearly as good as the hype suggests, and the pain only gets worse as your project grows.
- xingped 7y ago
  Why do you say that? What are some of the issues?
  - jrs95 7y ago
    The tooling is just unstable in general in my experience. You never know when things will get into a bad state and you have to kill everything and clear your caches and restart. And then in my experience styles don't actually behave the same way on iOS and Android. They also continue to make breaking changes so you always have to be worried about not only your own code but your dependencies handling that appropriately. The debugger itself is also prone to crashing and requiring full restarts at inconvenient times. Overall, I feel like the amount of random bullshit and platform specific workarounds I have to do makes it so I'm not really saving time VS having 2 native apps and I'm less confident about the overall quality of my software. There's also A LOT of valuable things in the native SDKs that no quality wrapper exists for, so you're missing out on a lot of productivity benefits of the underlying platforms.
mettamage 7y ago
I should've started a year later when ARC was introduced (I started learning between 2011 - 2013). Learning iOS dev with reference counting as a memory management system was really painful. My programming skill wasn't up to speed yet to "just" learn a new language. I only knew some university Java at the time. And while I did write impressive projects with it, I wasn't strong enough in an algorithmic sense. Learning a framework and learning memory management, and kind of needing to deal with pointers but not really proved to be too much. When ARC was introduced it was a breeze. Now, when I read this whole comment, nowadays I'd think: this is such nonsense. Memory management should not be a barrier to learn iOS dev. But when you're in that weird space of that you kind of know how to program (5000+ lines code) but you really need to get into it, and it doesn't feel natural yet. Then, yea, it does matter a lot. A few years later I learned C and had no issues learning pointers or memory management. To be fair, I didn't need to use any frameworks with C.
habosa 7y ago
Been doing Android development for 8+ years. The main thing to realize is that nobody actually knows what they're doing. You'll have a problem and spend hours and hours just searching for "the answer" but it's not out there. Everyone who has solved it has used their own hacks, and they're not going to be able to transfer the hack to you. Once you realize this it's somewhat liberating. You focus on the bug/feature and not the method. One time I was trying to solve a particularly nasty layout-at-runtime problem and just realized I could write my own ViewGroup and lay it all out myself, pixel by pixel, faster than fighting RelativeLayout or whatever. And that code is more stable than something where I import some library that's not going to be maintained.
m3kw9 7y ago
When doing custom UI animation code that isn’t native, expect 2-10x more development, testing and polish, and still won’t achieve it perfectly.
segmondy 7y ago
Go cross platform as soon as you can! Most folks preaching against it don't have the practical experience. If you're not writing games and writing a non graphic intensive app, it's the way to go.

237 points by toron123 7y ago

What do you regret you didn't know when started programming for iOS or Android?

I should’ve known that it’s turtles all the way down. Considering how many years I’ve sunk into programming for other platforms, this shouldn’t have come as a surprise, but I got suckered into believing that mobile computing platforms represented a significant enough paradigm shift to allow for starting with a cleaner slate. Not true! Having gotten into iOS development over the past couple of years, I’ve come to realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform. For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple’s latest and greatest programming paradigms. Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.

ken 7y ago
SwiftUI isn’t UIKit-specific. Display Postscript hasn’t existed since the OS was called NeXT, 20+ years ago, and was never on any iDevice. Cocoa is an alias for AppKit + CoreData, and iOS uses CocoaTouch instead.
- dahart 7y ago
  You’re right, yet this doesn’t directly address what parent said, in fact it’s somewhat agreeing with the point, that there’s a ton of influence left behind by these things, even though they are not there anymore.
- mattl 7y ago
  Display PostScript is in Apple Mac OS X Server 1.0 and then abandoned in favor of Quartz and PDF.
erokar 7y ago
> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed. I guess that's what Flutter is doing (for both iOS and Android).
- chooseaname 7y ago
  > I guess that's what Flutter is doing (for both iOS and Android). How does it do this as opposed to adding yet one more layer? Does it somehow get beneath all the cruft mentioned?
  - Signez 7y ago
    Flutter took the approach of treating the screen as a blank canvas. Everything is drawn using Skia primitives, exposed as Dart libraries. It has some downsides – they had to expose a lot of accessibility features on top of that using platform APIs – but it's quite nice when you are a developer, as you can Cmd-click on anything to learn how it is drawn, and use the same tools to build your own widgets if you need.
  - lhoff 7y ago
    Afaik Flutter is basically a Game Engine. Its not using the build in UI Toolkit instead rendering everything itself and just mimics the look of the native UI. I'm not completely sure about it, i just now it from listening to some talks.
  - wolf550e 7y ago
    Yes. It's not using any native UI widgets or UI code, but drawing everything itself using the lowest level API it can get, which I guess on iOS is Metal (and something for input). This means that the look and feel and the behavior and accessibility features will not match those of other apps (which do use the native toolkits), or the Flutter team will have to do a lot of reverse engineering and re-implementation to match that on each platform.
    - kitsunesoba 7y ago
gumby 7y ago
I consider this a feature: the older code has known behaviour, while a from-scratch implementation would have been a minefield of unknown bugs
- maxaf 7y ago
  I’m not buying your reasoning. Try putting a WKWebView into a SwiftUI view. This kind of thing is all sorts of messed up when multiple rendering systems - two of them declarative (SwiftUI and HTML) - collide in a single view. I’m sure someone’s going to call this a corner case, but useful and interesting apps that push the boundaries of the feasible are all composed of such “corner cases”. And hey, I’m not even doing anything outlandish: just trying to show some HTML.
  - gumby 7y ago
    I sympathize with your position and have had similar problems in the past. There’s no magic option. But typically the combination of a completely new API and implementation is very difficult for both implementors and users.
jayd16 7y ago
I think certain paradigms were completely shifted compared to the PC space. -Revamped permissions -App packaging/name spacing/consistent installation -IPC was redesigned as asynchronous Intent blobs on Android -Urls becoming first class citizens at the OS level -More consistent background app apis (and eventually better ways to track them) I could come up with more but I think there's actually a very big difference. But yes, its all built on top of older Java and obj-c libs.
simonh 7y ago
> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed. Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage. Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear. So legacy is a thing for a reason, taking one opportunity very often means giving up another.
deleted 7y ago
[deleted]

ddxxdd 7y ago

I regret not knowing about cross-platform development such as Flutter and ReactOS. I also regret not buying a book explaining all the concepts in as simple a manner as possible. As a semi-amateur programmer, I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile.

freehunter 7y ago
Agreed. This absolutely kills me when people say “just read the documentation” or “the documentation is very good” as a reason why they don’t produce examples or templates or starter kits. Not all of us are CS majors or programmers in large teams or with decades of experience to fall back on. Just reading the documentation isn’t enough to get me into a new framework or language. I need to see practical examples. For mobile development, this is why Expo was so crucial for me to understand how React Native works.
- afarrell 7y ago
  > I need to see practical examples And I need to see diagrams of mental models, though practical examples help solidify that. So one challenge with writing documentation is knowing what your audience needs. A better taxonomy of documentation would help solve this. For now, here is one I like based on https://www.divio.com/blog/documentation/ https://www.divio.com/blog/documentation/ - Tutorial: A walk through how to learn the basics as you build something. - Explanation: Showing the mental model of something - Guide: A walk through how to solve a specific problem - Reference: A comprehensive* listing of the API capabilities and how they are used. ------- If anyone knows of some good tutorials or explanations of mobile programming with React, I'd be grateful for recommendations.
- tonyedgecombe 7y ago
  Apple seems to be particularly bad for this, I was going through some of their videos recently and everything assumed prior knowledge. It's the same for much of the documentation. As much as I criticise Microsoft at least they have stuff like this: https://docs.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows https://docs.microsoft.com/en-us/windows/win32/learnwin32/le...

rowathray 7y ago

On the iOS side, I regret not knowing how horrible Xcode is and how horrible Apple's documentation is. On the Android side, I regret not realizing that no matter what kind of slick new well documented APIs Google releases we will all be writing code for Android 4.4 for the rest of our lives. Also, I wish I knew mobile developers are some of the lowest paid developers other than game industry peons.

FeistyOtter 7y ago
I have recently looked at surveys in my country and mobile developers are one of the most paid programmers out there, especially the ones experienced with Swift. What does cause the low pay in your country? Logically the sector is ever expanding and there is always demand for hires with any experience.
- deleted 7y ago
  [deleted]
unnouinceput 7y ago
this applies to web developers as well. too many devs on both web and mobile, so salaries are lower then rest of IT technologies. usually a web/mobile dev needs to know a lot more to make it on the same par, at which point you can argue is a full stack one anyway.
alkibiades 7y ago
as a mobile dev at the FANG companies, were paid the same as other engineers. in fact, some are paid more because of the smaller talent pool
vlozko 7y ago
> Also, I wish I knew mobile developers are some of the lowest paid developers other than game industry peons. I wish I can tell you you were wrong here but I only have anecdotal evidence. Maybe you’re stuck in a company that’s taking advantage of you with a low salary?
blackrock 7y ago

idrios 7y ago

I got pretty good at Android development and made a few apps that don't have many downloads but I'm still proud of and wanted to share with my friends and family. I regret that all of my friends and family have iPhones.

mikece 7y ago

I regret thinking that Xamarin was a good idea.

garren 7y ago
Amen. Management at a company I worked as were convinced that Xamarin was One True Path for mobile development. They were sold the idea that a Windows dev could instantly be productive in Xamarin without needing to understand the underlying platforms significantly. To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.
- pbourke 7y ago
  > but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project. What would you go with now?
  - mikece 7y ago
    Ionic. HTML, JavaScript, and CSS work on (darn near) everything.
ParanoidShroom 7y ago
haha been there, should have left for a different company with our cto thinking xamarin was the best.

pjmlp 7y ago

The years it took to realize how under-resourced the NDK team is, bothering to create my own NDK wrappers to work around the NDK bindings and forced JNI calls, manually dealing with dependencies across NDK projects. In retrospect, it would have been easier to just rewrite the whole thing in Android Java. Basically, how little Google cares for game related development workflows on Android. It just took them 10 years to acknowledge this, go figure. https://android-developers.googleblog.com/2019/12/android-game-sdk.html https://android-developers.googleblog.com/2019/12/android-ga...

karmakaze 7y ago

I can't really say I regret the path I've taken since had I not taken it, I wouldn't be able to form sound evaluations. I'd always sought out cross-platform development tools first on servers, then desktop, and mobile. Flutter/Dart comes closest at the moment but game engines might also work for certain apps. I'm glad I never bought into React-Native the worst of worlds. It's rare for an app to require native widgets and having to deal with two different sets and their idiosyncrasies isn't solving the problem.

trangon 7y ago

MVC, the way it’s implemented in UIKit, leads to code that is very difficult to test, mixes business logic and view layout and navigation, and leads to massive view controllers. You have to be very careful to avoid it.

wiradikusuma 7y ago

That JavaScript (and prior to that, Java) would work for mobile, one platform to rule them all. Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.

la_fayette 7y ago
I can only agree with that. If you build a web app within a we browser you can use whatever payment method you want and the platforms don't take 20% for every transaction...

datavirtue 7y ago

Xamaron Forms

la_fayette 7y ago

That mobile web apps aka PWAs are a perfect fit for classical data-driven applications. The return on investment for 2 native apps vs. a PWA is far...

izacus 7y ago
You're not allowed to use full PWA capabilities on iOS though right?
- la_fayette 7y ago
  https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7 https://medium.com/@firt/progressive-web-apps-on-ios-are-her... One can always build a hybrid app from a pwa...

McDev 7y ago

I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly. Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this. Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs. Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier. I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually. [0]. https://developer.android.com/topic/performance/graphics/load-bitmap https://developer.android.com/topic/performance/graphics/loa... [1]. https://developer.android.com/training/camerax https://developer.android.com/training/camerax [2]. https://square.github.io/retrofit/ https://square.github.io/retrofit/ [3]. https://github.com/android/architecture-samples https://github.com/android/architecture-samples

applecrazy 7y ago
Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.
- mdocherty 7y ago
  I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.

fit2rule 7y ago

That Apple and Google would move the goalposts so often, and with such vigor, that it'd result in classes of programmers who do nothing BUT support the mobile platform for development. It has been a nightmare of keeping up with the majors, just to be able to enter their carefully curated arena. Nowadays when I build an App, I do Linux/Mac/Windows first, and the iOS/Android release, next. Fortunately there is a vast industry out there for toolkits and frameworks for solving The Platform Problem™ which has been shoved down our throats by a ravenous corporate culture which is hell-bent on ensuring that they own the computing platforms of the future.

rowathray 7y ago
What, you don't look forward to WWDC to find out what syntax got arbitrarily changed with no explanation?

VLM 7y ago

For android, get good at handling null everywhere in everything checking all the time now, or learn it the hard way later. You'll be spending lots of time tracking down "wait, how could that have ever possibly returned a null?" Ditto async and observer and livedata type stuff. Never move data between things any way other than async. MVVM and all that, with caching repositories and stuff. Architecture changes fast enough that you have to be careful not to waste time and effort supporting some ancient version and NIH writing your own implementations of stuff that's newly added in current versions. Yet if you try to ship using cool alpha quality features, that's a whole different headache. For extra fun you can end up with both problems at the same time in different parts of the app.

neeloor2004 7y ago

I invested lot of years on Android because it is, promoted as open source etc ... but currently it is just their advertising platform, complete control of it developer (removing developer accounts, blocking apps and devices ) and full monopoly !!

self_awareness 7y ago

I regret not knowing that Android API is awful. Then I regret looking into Nativescript, because it was pretty buggy. Then I regret not knowing about Flutter earlier. THEN I regret not knowing that Flutter is pretty buggy as well. Next step is me trying to learn other frameworks, like Cordova or React Native. I wonder what my regrets will be.

alkibiades 7y ago
all software is buggy
sansnomme 7y ago
If you want an idea of how good PWAs can get check out Pinafore: https://github.com/nolanlawson/pinafore https://github.com/nolanlawson/pinafore Runs better than most native apps.
stevewodil 7y ago
Flutter is quite good, what were some of the issues you experienced? The one PITA for me is state management, but once you understand how to solve that using BLoC or Providers then it should be relatively usable
- self_awareness 7y ago
  Well since you ask: Flutter is good, but it's also buggy. 1. Problem with Cupertino theme on Android - https://github.com/flutter/flutter/issues/42988#issuecomment-574399565 https://github.com/flutter/flutter/issues/42988#issuecomment... -- only point 1 from this post matters, because point 2 was resolved by a helpful person below the post. But point 1 is still unresolved, and it looks bad. 2. Flutter runtime simply crashes on some mobile phones when loading the app. I've released an app on old SDK, and with every update of some minor thing + SDK I'm getting reports about new crashes from people who rated the app 5 starts on older SDKs, because it was working for them earlier. I've tried to report it: https://github.com/flutter/flutter/issues/43240 https://github.com/flutter/flutter/issues/43240 but my issue was grouped with some unrelated problem, and my questions were ignored. 3. I think the x86 codegen in Flutter is sometimes buggy. I've used a ZIP compressor/decompressor library written in pure Dart and it sometimes crashed in random location after using the library. I've tried to debug it but there was no pattern for the crash. The crash also was happening on the system level (SIGSEGV) instead of simply throwing an exception that would be catchable by Dart. When testing on the mobile phone, so when ARM codegen was used, I've observed no crashes and no problems when using the archive library. 4. Google AdMob has poor support for Flutter. The official AdMob lib doesn't support native ads, and is incompatible with widgets that draw an always-on-top layer, like Drawers or Action Buttons at the bottom right corner of the screen. It IS possible to finally work out the solution by using some thirdparty library which uses AdMob in a hacky way, but I would expect something better for one of the most crucial Google services like AdMob. 5. Until recently there was no support of Cupertino theme's i18n. I had to manually translate all texts of Cupertino theme to a different language (like 'copy', 'paste', etc). I've released two apps in Flutter but I'm afraid to update them, because something always breaks after update.

tomerbd 7y ago

flutter.

dfansteel 7y ago

Don’t underestimate the value of build tools. Just because you know Xcode and Swift or Android Studio and Kotlin (or their antecedent languages) are you done. Finally having a senior dev who knows what he’s talking about has done more for me in the past two years than the previous 8 of reading blog posts and hacking. He’s shown me the real value of build scripts. Today even my personal iOS projects are dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up but I can prove that my code works.

ismail-khan 7y ago
Would you mind elaborating on how build scripts helped you (what problem did you solve?) and sharing learning resources?
ronsor 7y ago
>...dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up... Can you elaborate on this? It just sounds like you have unnecessary complexity.
Lich 7y ago
Can you explain more? I'd like to learn more about this.
- deleted 7y ago
  [deleted]

mobiledev2014 7y ago

It depends somewhat on why you ask. A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don’t plan to maintain long term, I’ll give them that. I know it’s cheesy but my only regret is I didn’t go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you’re early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it’s best to keep a healthy distance with things that only support the newest OS. For instance I wouldn’t build an app in SwiftUI yet but I follow it like a hawk because it’s likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must-know this decade. Mobile dev is so rewarding! Every developer should at least dip their toes in.

MarvelousWololo 7y ago
As a front end dev I’ve been thinking about it for so long but honestly I don’t know what I should build or study first.
- mobiledev2014 7y ago
  It’s always best to work on something you’ll actually use. Maybe think about an app you already use but want to improve or simplify (a to-do list without the frills for instance). As far as learning, I think this Stanford course is the best way (though not for those who aren’t absolute beginners to programming). I notice it hasn’t been updated lately but it should be current enough https://www.youtube.com/watch?v=TZL5AmwuwlA https://www.youtube.com/watch?v=TZL5AmwuwlA

kitsunesoba 7y ago

That developing for Android isn’t even as half as smooth as developing for iOS. Yes, with iOS you’re using Xcode and have to set up provisioning for your dev device and all that, but once you’ve done that you’re mostly on your way. UIKit, while not the shiniest thing out there, is quite competent and functional — you can easily write world class apps with it while keeping third party libraries to a minimum. On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness. If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I’m not holding my breath.

mst 7y ago
> You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"
- mntmoss 7y ago
  The best-case end result of this instability, of course, is the "double interface" - an interface abstraction on top that talks in terms of the domain problem, and then a second layer to convert the lower level interfaces into that abstraction. Unfortunately GUI is particularly fiddly and difficult to write the double interface for, since you get a "thousand words is one picture" problem: it doesn't reduce well to text.

vbsteven 7y ago

I regret it took me 5 years of mobile development (both platforms) to realize I really don’t like writing GUI code. I switched to backend and infrastructure work and I’ve been a lot happier since.

luxuryballs 7y ago

I built an iOS game using Sprite Kit and had to hack together support for multiple screen sizes later which was kind of a pain. Likewise they make you provide an app icon of like 25 different sizes. Have not done standard UI work yet but unless you use a “reactive” set of layouts I can only imagine the pain.

m3kw9 7y ago
Yeah if you plan the development around different screen sizes in beginning would be best, otherwise architectural changes will prob be needed unless like you side to hack it

aquabeagle 7y ago

I wish I would have not fought the tools so much. I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap). Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.

vlozko 7y ago
Code-only purists are still prominent in the iOS community. Yeah, there’s definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.
- rimliu 7y ago
  I actually went the other way. With autolayout is just easier (for me), to do UIs in code. Especially because IB does not offer 100% of what UIKit has. I don't hate IB, it just become less relevant to me. Storyboards on the other hand… Never thought well about them.
- dep_b 7y ago
  I’m not against IB but the lack of stuff like constants is really difficult when a customer demands “same app, different skin”. SwiftUI seems to fix this.
- cloudwalking 7y ago
  IB files are essentially impossible to code review.
  - m3kw9 7y ago
    If you read the storyboard diffs the layout code is human readable, just need to get used to it. Although there is no docs

allo37 7y ago

On Android, that there hasn't been much love for C/C++ and the NDK is full of interesting pitfalls: Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense. Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense. The camera was a party too, added a listener for Camera session events and the app crashed. Yay.

georgemcbay 7y ago
The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then. All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app. This is kind of a theme in Android (or was... my experience is slightly out of date right now). As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression. Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.
- pjmlp 7y ago
  It still is the same theme. For Vulkan and real time audio they expect you to checkout GitHub repos and compile from scratch, instead of having the tooling as part of the NDK. Likewise after 10 years they still expect everyone to manually write JNI bindings, instead of providing another productive way for language interop.
- allo37 7y ago
  Well, glad to hear it's consistent at least :) Good news is we got a handle on all the little issues and now our code runs well on a wide selection of devices, but yeah, next time around I'd find a library that handles all the gory details. I find image manipulation works pretty well, though I've only been doing Android dev for 2 years so maybe it's improved. Or I just haven't done anything 'fun' yet...

hyko 7y ago

Example code is invariably dross from an architectural point of view. Unit tests are still valuable in a mobile environment. Most good apps are simple. Simplicity is not easy. Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It’s impossible to predict which category an aspect belongs to ahead of time. There are times to embrace the approach taken by a platform, and times to distance yourself from it. Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys. The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.

peterdekr 7y ago

I develop for Android since 2011. Since 2016 I also do more iOS. I mostly regret not looking into new developments faster. Things like Kotlin and Architecture Components. They are great, so at least experiment a bit with them to see what all the fuzz is about. Try to keep up! Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth. I also regret everything about Objective C ;)

usrusr 7y ago

On Android: being paranoid about multithreading in all the wrong places before I stopped worrying and love the main thread. Move actual work off thread whenever possible, but never try to integrate off threat memory access by hand using synchronized and friends, just enqueue your final result plumbing on the main looper. Be paranoid about multithreading in the right places, particularly when you hand a callback to some black box. A callback that checks the thread it's running on to enqueue itself on main if necessary might become a familiar pattern. You might start to hate all callback methods that don't return void.

smallstepforman 7y ago

If you built it, they wont come. Without marketing, the odds of your customers discovering the app (amongst a sea of garbage) are insanely low. I tried a Tennis app in 2009 and even back then it was competing with hundreds of other apps, now its mist likely 10’s of thousands. Heart breaking.

ronyfadel 7y ago
Sometimes if you build it, they will come. I launched a music app in 2012 (student project), and over its lifetime (6 years), I had 95k downloads and 7 million sessions on the app.
- m3kw9 7y ago
  Some apps have very low viral aspects like biz apps or Utils, also some standalone single player games. They will be at the bottom of a search result of 100s when first released. Quite demoralizing
mantap 7y ago
Word of mouth marketing can be strong. For example I have purchased many apps because of a recommendation IRL, mostly music-focused (musicians love to talk about their kit). The point is to make something truly excellent, and if possible, conspicuous.

sehugg 7y ago

I started with iOS in 2009. I wish I hadn't used Core Data, and made the decision to store lots of large binary blobs in it. Changing the schema became impossible, because the migration process often crashed or ran out of disk space in production. That, coupled with lots of Core Data crashes that persist (pun intended) to this day. It may have been easier to just use SQLite directly. My decision to use NSThread for worker threads wasn't optimal either, but there weren't many async options in 2009 (Remember ASIHTTPRequest?)

conductr 7y ago

The whole damn thing. I’m self taught web developer, server management, backend stuff. I love a Rest over HTTP API. X Code and all the sims do not jive with my brain. Swift helped a bit. But only ever able to build a bouncing ball game. The process of launching on an app store alone seems insane. I started by FTP and Perl then PHP. I pay people to write code these days.

jamil7 7y ago

To get into mobile sooner. I was tired of the web and burned out needed something different. I’m getting way more work and enjoying myself a lot more. I hope to have a long career programming so maybe I’ll change platforms again one day.

winrid 7y ago

How hard it would be to Port.

ngcc_hk 7y ago

That you need a singleton pattern to ease the gps refresh problem. Totally rewrite the program before submit to Apple store.

debt 7y ago

The xcodebuild command line tool is insanely powerful. The one provided by vanilla Xcode is awful.

ryandrake 7y ago

If you think you will ever be cross platform, do yourself a favor and write as much of the business logic as you can in C++ or C. The platform-specific piece should be small and “just enough to make the platform happy”. Do everything else portably from the start.

Groxx 7y ago

The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets): Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things. It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your core logic is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores. It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.

rmdashrfstar 7y ago
Related to this is “clean architecture”. Your code should not be dependent on a feature-laden framework. You should focus on writing your business domain and rules, then separately orchestrate your domain, and connect the UI and other external frameworks as interfaces to the lower, or more generic, levels of your application. This is a general software design principle that allows for your UI to be free to change without affecting your core logic and rules, while also making all of your code more unit testable.
richard78459 7y ago
With React hooks or android component life cycle its hard separate the framework and logic. How do you do it ? Any recommended books or other resources ?
- Groxx 7y ago
  React's behavioral features are relatively difficult, I'll grant, but it's entirely possible to use it as a relatively dumb "render X efficiently for me" target. If you're using hooks heavily, you're deeply entangling your code with the framework - that's your choice, but yeah, it comes with consequences as well as benefits. Android lifecycles are probably the main target of my comment tbh. They're abysmally complex and make any kind of state management incredibly error-prone. As a tradeoff for that complexity and losing a lot of control, if (and only if) you go all-in on them, you get decent state reviving after process death, which can do really slick things like "app crashed" -> it just appears to go back one screen. Instead, you can write your app as e.g. an in-memory singleton somewhere. You can even do that in a different thread if you want, leaving your UI impossibly smooth (at increased risk of "tap x" -> "nothing happens"). Design your own lifecycle that makes sense for your app (which probably looks very little like the Android lifecycle, especially when you throw in fragments...) and trigger/wait on the external world of the Android framework as needed. Odds are pretty good that you'll take multiple things from Android and combine them into one in yours, and potentially vise versa (e.g. multiple actions from your app become view updates in a single activity, rather than multiple activities. or do everything in one activity, it's often far better performance anyway, and much easier to control in fine-grained ways. importantly, your core logic doesn't care, unlike if you put that logic in the activities).

sshb 7y ago

On iOS: • Interface builder(especially Storyboards) is inferior to using UIKit straight from code • Coordinator pattern, which lets you split logic and view controllers. https://www.hackingwithswift.com/articles/71/how-to-use-the-coordinator-pattern-in-ios-apps https://www.hackingwithswift.com/articles/71/how-to-use-the-...

balladeer 7y ago

I wish I had realised that Android app development ecosystem (the dev tools, API, documentation, gradle, dependency management etc) is a shit show and is going to remain a shit show and I should have moved to backend early in my career. Now companies are very reluctant about it.

Aduket 7y ago
reluctant about what? backend developers?

jrs95 7y ago

React Native isn’t nearly as good as the hype suggests, and the pain only gets worse as your project grows.

xingped 7y ago
Why do you say that? What are some of the issues?
- jrs95 7y ago
  The tooling is just unstable in general in my experience. You never know when things will get into a bad state and you have to kill everything and clear your caches and restart. And then in my experience styles don't actually behave the same way on iOS and Android. They also continue to make breaking changes so you always have to be worried about not only your own code but your dependencies handling that appropriately. The debugger itself is also prone to crashing and requiring full restarts at inconvenient times. Overall, I feel like the amount of random bullshit and platform specific workarounds I have to do makes it so I'm not really saving time VS having 2 native apps and I'm less confident about the overall quality of my software. There's also A LOT of valuable things in the native SDKs that no quality wrapper exists for, so you're missing out on a lot of productivity benefits of the underlying platforms.

mettamage 7y ago

I should've started a year later when ARC was introduced (I started learning between 2011 - 2013). Learning iOS dev with reference counting as a memory management system was really painful. My programming skill wasn't up to speed yet to "just" learn a new language. I only knew some university Java at the time. And while I did write impressive projects with it, I wasn't strong enough in an algorithmic sense. Learning a framework and learning memory management, and kind of needing to deal with pointers but not really proved to be too much. When ARC was introduced it was a breeze. Now, when I read this whole comment, nowadays I'd think: this is such nonsense. Memory management should not be a barrier to learn iOS dev. But when you're in that weird space of that you kind of know how to program (5000+ lines code) but you really need to get into it, and it doesn't feel natural yet. Then, yea, it does matter a lot. A few years later I learned C and had no issues learning pointers or memory management. To be fair, I didn't need to use any frameworks with C.

habosa 7y ago

Been doing Android development for 8+ years. The main thing to realize is that nobody actually knows what they're doing. You'll have a problem and spend hours and hours just searching for "the answer" but it's not out there. Everyone who has solved it has used their own hacks, and they're not going to be able to transfer the hack to you. Once you realize this it's somewhat liberating. You focus on the bug/feature and not the method. One time I was trying to solve a particularly nasty layout-at-runtime problem and just realized I could write my own ViewGroup and lay it all out myself, pixel by pixel, faster than fighting RelativeLayout or whatever. And that code is more stable than something where I import some library that's not going to be maintained.

m3kw9 7y ago

When doing custom UI animation code that isn’t native, expect 2-10x more development, testing and polish, and still won’t achieve it perfectly.

segmondy 7y ago

Go cross platform as soon as you can! Most folks preaching against it don't have the practical experience. If you're not writing games and writing a non graphic intensive app, it's the way to go.