
Ask HN: What do you regret you didn't know when programming for iOS or Android? - toron123
What do you regret you didn&#x27;t know when started programming for iOS or Android?
======
McDev
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/loa...](https://developer.android.com/topic/performance/graphics/load-
bitmap)

[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
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
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.

~~~
freehunter
On the other hand, very few applications need to scale to the point where it
matters. If the options are "ship something now and refactor later" versus
"ship something in six months that's perfect but too late", most people here
would benefit from cross platform solutions.

Very few companies have ever failed because their tech stack didn't scale
well.

~~~
SquishyPanda23
This is a nit, but there's a pretty big difference between refactoring and
rearchitecting.

If you plan for an eventual migration of the app from a cross-platform toolkit
to native, then often you're committing to a significant rewrite of the app.
This means either you dedicate a team to the rewrite or you stop adding
features while it gets rewritten.

Plus it will take a while for the native version to get feature parity with
the cross-platform version, and you typically can't roll out the native
version until you have parity.

I'm sure there are tools and strategies for getting this right, but I've seen
this basically kill startups.

~~~
K0SM0S
> _“I 'm sure there are tools and strategies for getting this right, but I've
> seen this basically kill startups.”_

Well if they're doing it like that, it's indeed not much better than hara-
kiri. There are better ways :)

How you do it is incrementally, avoiding too-major changes at once, and
progressively moving from codebase A (cross-platform framework) towards
codebase B (new native thing). But it happens at the integration level, i.e.
you build with increasingly more % from B, but during the whole A->B
transition it'll be a hybrid build.

E.g. part Flutter / part native.

1\. You begin with "let's take camera stuff out of Flutter and re-implement
our related features using native APIs": this instantly makes two apps (iOS,
Android) with 90-99% code in common, just a fork to handle camera APIs
separately (by the way, the state of API affairs often forced you to do this
to some extent for any non-trivial use-case; I'd wager it used to be the state
of most feature-rich apps in the 2010s).

2\. Then you proceed with another component of your app. Rinse and repeat
until you've got 90% from B and the remaining stuff is structural.

3\. All that remains is to remove Flutter entirely from the equation and
rewrite your core app logic: what glues all of the above components together;
all of which at that stage are already rewritten for native and tested
independently (critical to your success).

Along the way you never truly break UX, it's more of a classic "ongoing
development" thing with details changing here and there, and hopefully better
UX each step since your move to native must be motivated by something worth it
for the client-side (otherwise it's likely your server API model that needs
refactoring).

That's how the now-default-consensual approach to how you change stacks
without breaking UX, nor your company. Full rewrites on wholly new tech is
just asking for cataclysm: you literally do that to yourself, to your own code
and users. It's also the only reasonable way I know for small teams, one-man
shows, etc.

~~~
ngcc_hk
Make sense. And may be should start with this thinking when I started to avoid
the first pain.

------
maxaf
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
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
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.

------
mobiledev2014
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
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
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)

------
aquabeagle
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
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.

~~~
cloudwalking
IB files are essentially impossible to code review.

~~~
m3kw9
If you read the storyboard diffs the layout code is human readable, just need
to get used to it. Although there is no docs

~~~
generalpf
Not in the case where a bunch of views are moved inside a new view. Then the
XML diff is really janky, and elements are assigned new IDs.

The constraints are impossible to code review in XML since they refer to
elements by IB ID which is essentially obfuscated. I don't understand why IB
doesn't let you give the elements their own human-readable IDs.

------
kitsunesoba
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
> 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
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.

------
Groxx
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.

~~~
richard78459
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
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).

------
ddxxdd
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
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.

~~~
wool_gather
Apple _used to_ have a lot of pretty good (not perfect, but pretty good)
conceptual/architectural documentation. Most of it has sadly been sunset, and
is hard to find, even though it's still largely applicable. And it hasn't been
replaced -- hopefully that's just "hasn't been replaced _yet_ ".

~~~
Ididntdothis
Apple documentation in the 90s was a piece of beauty. Microsoft's was pretty
good too back then with MSDN Library CDs.

------
self_awareness
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.

~~~
darksaints
Cordova and react native are going to disappoint you for the same reasons.

~~~
Ididntdothis
Everything sucks in its own sweet way :-)

------
allo37
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
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
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.

------
smallstepforman
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
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
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

------
pjmlp
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-
ga...](https://android-developers.googleblog.com/2019/12/android-game-
sdk.html)

------
dfansteel
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.

~~~
Lich
Can you explain more? I'd like to learn more about this.

------
habosa
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.

------
vbsteven
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.

------
hyko
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.

------
fit2rule
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
What, you don't look forward to WWDC to find out what syntax got arbitrarily
changed with no explanation?

------
wiradikusuma
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
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...

------
VLM
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.

------
idrios
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.

------
peterdekr
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 ;)

------
mikece
I regret thinking that Xamarin was a good idea.

~~~
garren
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
> 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
Ionic. HTML, JavaScript, and CSS work on (darn near) everything.

------
sshb
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-...](https://www.hackingwithswift.com/articles/71/how-to-use-the-
coordinator-pattern-in-ios-apps)

------
usrusr
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.

------
karmakaze
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.

------
sehugg
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?)

------
la_fayette
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
You're not allowed to use full PWA capabilities on iOS though right?

~~~
la_fayette
[https://medium.com/@firt/progressive-web-apps-on-ios-are-
her...](https://medium.com/@firt/progressive-web-apps-on-ios-are-
here-d00430dee3a7)

One can always build a hybrid app from a pwa...

------
mettamage
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.

------
conductr
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.

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

~~~
xingped
Why do you say that? What are some of the issues?

~~~
jrs95
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.

------
ryandrake
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.

------
jamil7
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.

------
trangon
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.

------
m3kw9
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.

------
luxuryballs
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
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

------
balladeer
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
reluctant about what? backend developers?

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

------
neeloor2004
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 !!

------
segmondy
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.

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

------
winrid
How hard it would be to Port.

------
tomerbd
flutter.

------
rowathray
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
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.

