Coinbase rewrote both their Android and iOS apps in React Native, and are happy with the end result.

My takeaways from their writeup (thread)

1. It's hard to hire good lots of native mobile engineers. Heck, this is what was probably a major trigger for their whole transition
1. (Cont'd) Coinbase had a strong React team, and not enough native engineers... and thought they could solve two problems at once. Fewer engineers, higher efficiency. blog.coinbase.com/announcing-coi…

Sounds like they might have succeeded with this (at least for now)
2. It takes a *lot* of investment to ship any mobile app at scale, RN not different. This is a post from Nov 2020 on the performance challenges their team needed to solve: blog.coinbase.com/optimizing-rea…
3. RN is not a great choice to build cross-platform *features*: it's no alternative to e.g. shared native code via KMM or C++. If you do it, going all-in is what makes most sense.

It's not a short journey: took Coinbase 2 years to pull off. blog.coinbase.com/announcing-coi…
4. You can make any technology work at scale if you have enough resources (people) to iron out its kinks. PHP to run for billions? Facebook ✅quora.com/Is-Facebook-st…. RoR at scale? Shopify ✅

Coinbase did a LOT of under the hood work with RN as well.
5. Choosing a mobile technology will significantly impact who you can (and want to hire).

Airbnb saw they were able to attract fewer native engineers & this was a contributing reason they eventually went back on RN as well medium.com/airbnb-enginee…

For Coinbase: not an issue now.
6. What do I think about the "best" mobile technology to choose? Full native? Flutter? React Native? Kotlin Multiplatform? RIBs? Something else?

I cover all these in mobileatscale.com (free as a PDF for another 2 weeks).

It's all tradeoffs: just like on the backend & web.
Tell me which is the "best" backend technology to build at scale. Go? Java? .NET? Node? Rust? RoR?

You can make it all work, even exotic ones like Erlang (e.g. Whatsapp).

The same is true for mobile frameworks. Choose based on your constraints and needs. Avoid blindly copying.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Gergely Orosz

Gergely Orosz Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GergelyOrosz

13 May
I am hearing several senior engineers in hot fields in the EU getting +50-100% in compensation offers from US startups and tech companies... and many of their current employers matching, or partially matching them as counter-offers.

My theory on what's happening (cont'd):
1. COVID made remote work an everyday thing
2. Funding for certain startups is very strong in the US
3. These startups struggle to hire anyone good for $200-250K/year in the US
4. But they can hire *amazing* people in the EU, who are just as good professionally
(cont'd)
5. These EU companies are doing the math & realize it will be a lot more expensive to backfill the person leaving, as the market for sr engineers is moving up (see #2 & #4)
6. They make a counter to not lose the institutional know-how
7. Many of these people actually stay!
Read 7 tweets
11 May
I helped a few software engineers negotiate an extra €20-40K/$30-50K in annual comp at tech companies in the EU and the US.

Here's the advice I gave them (thread).

1. Know what is negotiable. At many companies, salary has little wiggle room. Equity & signing bonus does.
2. Understand how equity works: usually this is where you can negotiate a lot, and it can convert to real money. Details: blog.pragmaticengineer.com/equity-for-sof…

3. Once you get an offer, you can *always* do a round of negotiation. Don't commit on the spot: but ask for time to review it.
4. If you don't have competing offers: get data on what the company or competition's range will be. Blind, levels fyi are good sources, and I'll also publish data points for EU here: pragmaticurl.com/salary (WIP)
Read 7 tweets
6 May
My economics of selling books:

$20 book on @Gumroad - I net $19 (Gumroad takes 3.5% + $.30)

$22.50 print book on Amazon - I net $9.50 (Amazon takes 40% of the sale price + $4/book KDP print)

$22.50 Kindle on Amazon - I net $7.70 (Amazon takes 65% of the sale price)

(cont'd)
$22.50 book bought in a US bookstore, fulfilled by Ingram Spark - I net around $5.86 (55% wholesale discount)

$22.50 book bought through iBooks - I net $9 (listed it through Ingram Spark)

I did not go through book publishers, but here's how amounts would look, from contracts:
A $22.50 book through:

A "classic" publisher: $1.50-2/book (with a "classic" publisher like O'Reilly, Manning or similar: 10-12.5% royalty from the net price)

Smaller publishers (e.g. Packt): $2-4/book (up to 20% of net)

The Pragmatic Bookshelf: up to $11 (50% in royalties)
Read 5 tweets
4 May
More than five years ago I decided to take tech blogging more seriously, and started The Pragmatic Engineer.

This year I’ve made more directly and indirectly from writing books than my comp would have been at Uber. None of this would have happened without starting that blog.
I get questions from people one day hoping to do something similar.

A few things:
1. I never planned for it. I quit my job at Uber for a variety of reasons, and enough savings to get by for a few months, while I write @EngGuidebook, that is a bucket list item of mine (cont'd)
2. Few people give away quality resources for years, consistently. My blog did this, helping many people in various ways.

3. Distribution is the biggest barrier for writing any book. The fact that I had a large group of people who trusted me (see #2) made a large difference.
Read 5 tweets
22 Apr
7 mobile eng industry predictions after months of research for my book, Building Mobile Apps at Scale:

1. Kotlin Multiplatform will become the de facto *native* way to share code between iOS and Android. KMM is maturing rapidly & is easy for iOS engineers to also pick it up.
2. Flutter will become the most popular way to build cross-platform apps.

The only downside is having to learn Dart. Otherwise, it's fast & tooling is solid. Google has gone all-in, building many of their own apps 100% Flutter. Cannot say the same with RN & other alternatives.
3. Full-native mobile development is not going anywhere with large apps with millions of users.

Having full control of the UX & the ability to immediately make use the latest APIs will be key for many apps and platforms.

Flutter, RN, and others will not take over all the space.
Read 10 tweets
20 Apr
The two-sided marketplace nature of job seekers/jobs, how you should use it to your advantage, and how the explosion with remote work (in software engineering) is changing this balance for juniors & seniors.

Thread for anyone job searching now, or in the future.
The job market *always* starts from the companies who hire. They have the budget, and need someone with a specific skillset. They post a job, and get (and often also source) qualified applicants.

There's a huge difference between popular & unpopular ones though:
The job market is a "sellers market" when there are a lot fewer jobs than qualified ppl who want to apply or change jobs. Recessions are good examples of this (in software: 2001, 2008, and some sectors now).

When this happens, even less popular companies see a lot more interest.
Read 17 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(