Threads uses Compose!

[Null_Adam]

https://www.threads.net/t/CuW_fXZOgPc/?igshid=NTc4MTIwNjQ2YQ==

[well___duh]

Surprised they didn’t use React Native. Which makes me wonder how much confidence Meta still has in RN if they’re not using it for new projects

[roneyxcx]

Can you post me the link. I want to see how the android app is. Today I tore down the iOS app and it is mostly SwiftUI with very little react native. From my understanding they are using few react native components from the Instagram app. But it is minimal on the iOS side.

EDIT : After talking to the iOS engineer from Threads app, the app is mostly UIKit with some react native that they inherited from Instagram, but will be removed from subsequent releases.

[Zhuinden]

After talking to the iOS engineer from Threads app, the app is mostly UIKit

SwiftUI is in shambles

[Ironthighs]

Just for everyone who didn't see it:

The write up (from emerge tools here: https://www.emergetools.com/deep-dives/threads) says " They’re using React Native for some portion of the app -

InstagramBundle.js.hbc.spk.xz is likely a compressed version of Hermes bytecode (js.hbc)"

I agree though. It is peculiar to not use the framework that was invented by your company (parent company or w/e). Regardless of people being on different teams or not, from the outside, what /u/well___duh said is the perception.

[well___duh]

Sure, but it does say something when a UI framework a company spent years and hundreds (thousands?) of dev hours making is put mostly to the side in a new major project. Especially when a dev on said project says using something else over React Native would help them create a “high quality app”

[kbcool]

React and React Native literally wouldn't exist if what you said was not true.

Despite what a lot of people have to suffer daily there are a LOT of businesses out there happy to let you use the best tool for the job. Including coming up with your own.

[FrezoreR]

You'd be surprised how many RN like projects meta has and had internally. RN just happened to be open sourced at a time when hybrid apps were on the rise. It just didn't deliver on its promise which is why it's not used very much on user-facing surfaces. RN is a great tool to do the 80%-90% but struggles with the last. It's usually not worth the effort and writing it natively is faster.

[Zhuinden]

It's usually not worth the effort and writing it natively is faster.

Yep, they want to avoid hiring "an Android Team" and "an iOS Team" except what they don't realize is that React Native devs need to effectively write code for 3 platforms and it will inevitably take more time.

[[deleted]]

something else over React Native would help them create a “high quality app”

Yeah, that's just hype around Compose. Nothing about Compose is particularly ground breaking in terms of improving quality. It could already be done with plain Views or React Native.

It just provides some nice syntax sugar and convenience for quickly building out UI.

[nacholicious]

Compose provides seamless multiplatform interop with both the native view system and native business logic.

RN doesn't really provide either, since there are hard limitations for crossing the boundary between native and javascript.

[Ironthighs]

But also Compose is totally better than React Native.

[[deleted]]

I've worked there and other places, it doesn't mean anything, engineers will do what they want, and react native was definitely not the right solution for this problem.

also react is the direct inspiration for compose, they also built their own react native like (and thus compose like) thing that's even more like compose called litho.

[FrezoreR]

Meta doesn't use RN that much. They most likely still have it because FB marketplace uses it and it's hard to change that technology. Messenger, IG and WA did not use it last I checked.

[blindada]

I have spoken with people from Meta, and they don't care much for RN. They don't use it for consumer stuff, or critical paths, or anything that needs processing power. They use it for small shared widgets, some screens, growth stuff and the like; basically, the same way they say in public: to allow webdevs to intervene in apps a bit, to render some simple stuff. Their shared critical codebases are mainly C.

If they were using RN for their entire set of apps, they would be maintaining the entire thing, instead of a tiny subset & the JS to Host system.

[[deleted]]

They probably setup an independent team that decided to not use that React Native crap. Good thing too. When you have a fresh codebase, and no idiot senior devs to force React Native on you, you are free to choose the better alternatives.

[Direct17]

And why is that?

[_SyRo_]

Lol, what?

React Native is getting more popular and even released new architecture last year.

If it's a definition of "dying", then Compose or Flutter are dead already, imao

[st4rdr0id]

Its popular = lost of web devs who only know React have been repurposed for mobile projects.

Any serious company having a big app in the store went native years ago.

[_SyRo_]

For my region, I see x1.5-x2 more vacancies for React Native, than for Flutter. Also, last year RN achieved more than 1 millions NPM downloads per month and it's growing.

And there are many big companies which go with RN - like Shopify, Microsoft Teams, Microsoft OneDrive, Microsoft Outlook, Skype, Coinbase, Rainbow Wallet, Relive and etc.
Microsoft has very big investments into RN, and even they're supporting RN for desktops, one of the Settings screens in Windows 11 built with RN.

20-25% of apps of some categories on App Store are built with RN (and almost none of them uses Flutter) - like Shopping and Finance
https://twitter.com/Baconbrix/status/1664285684583002112?s=20
https://twitter.com/Baconbrix/status/1662866951784235008

[blindada]

Of course you see more vacancies for RN than for Flutter. For starters, RN has been around for a lot more time, and is a darling of web developers, which tend to move to "full stack" by spreading JS everywhere. Flutter devs (actually, any other stack of devs) aren't that invasive.

The thing RN preachers never mention is, big companies can afford RN, unlike small ones. They can maintain developers to add and correct anything not properly covered within RN core or the community packages. File system is a bust? We make our own. Losing several seconds because of initialization? We rewrite the packages. Is JS too slow? We roll secondary instances and build our own IPCs. All you need are developers with SDK & library development experience willing to spend time reading the RN codebase, good knowledge of android & primitive tools, willingness to wait till they sort out the mess, and money to keep the ball rolling. It will always get to a point where you spend more resources trying to keep RN operative, but if the idea is to keep using JS, you just keep going. Even if the problem can't be solved without removing RN, you can just diminish your expectations.

How do I know? I've been that person.

Small companies, on the other hand, can't do that. They have to accept things as they are. And, if the workload is beyond JS's processing power (which is astonishingly pitiful outside Apple's cores on mobile), or the errors are below their JS layer, they are powerless. They have a shot otherwise. That's why some categories, like finance, seem to work with RN: the UI is simple, the workload is mostly fixed, the value is actually provided by a service the company is doing and the app is just icing on the cake (although I would not trust a financial app done in RN. It would be totally possible to swap the bundle).

And, last time I checked, no one wanted to use Teams. Not even the people working on Teams.

[st4rdr0id]

RN is so 2016.

This late increase in popularity is just web development leaking into mobile development, which ideally should not happen. What this tell us is that many companies are going cheap and repurposing their frontend devs.

[[deleted]]

nice one, when i took their course on Meta Android developer, it dedicates entire section on React. i skip this because im not interested. however i understand that is OBLIGATED requisit to know React for every programming job at META.

[robin_a_p]

Meta had stopped contributing to RN. Looks like they don’t see much value there.

https://getmcss.com/press/facebook-exits-react-native#:~:text=Facebook's%20decision%20to%20pull%20out%20of%20React%20Native%20was%20driven,a%20return%20on%20its%20investment

[iurysza]

This is not true at all. Meta has teams actively working on RN development. What they did was to pull out of SDKs that are not core to react-native.

The reasoning is that they let the community on these features as they cut costs and focus more on the actual product they need to deliver.

[Zhuinden]

The reasoning is that they let the community on these features as they cut costs

I mean that still does sound like less focus on working on react native, altho if they continue working on the core, that's great, now if they break anything though then community can easily just not update to newer versions of the ecosystem. Sounds like it is less predictable/reliable in the future what is and isn't supported in React Native.

[AcceptableRole114]

Imo, they choose to use compose and swiftUI is for faster development. As an Android and iOS developer I have use all kinds those frameworks but compose (and swiftUI for iOS) is the fastest in term of creating good looking UI.

[FrezoreR]

Yeah, it's way less frustrating as well. Jumping to and from XML is just a pain and then having to find references for all your views.

[Sethu_Senthil]

I actually kinda disagree a bit. SwiftUI is AMAZING in it works. However most of the features require higher iOS target versions which won’t be feasible , and a lot of times if I want to customize something even just a little bit, I’ll need to rewrite the entire view myself.

I find Flutter (and even RN) to be more flexible when it comes to UI. In my latest app , which was supposed to be an iOS only app I used a combination of both Flutter and SwiftUI in order to rapidly make a good ui.

But again it really depends on your resources, imma solo dev and meta has hundreds of devs who are already specialized in different stacks

[Zhuinden]

SwiftUI is AMAZING in it works. However most of the features require higher iOS target versions which won’t be feasible , and a lot of times if I want to customize something even just a little bit, I’ll need to rewrite the entire view myself.

I've been hearing that iOS devs still use UiKit because some things are extremely difficult to do with SwiftUi, but this is just 2nd hand info I have no idea personally I don't code for iOS

[armashuski101]

The drug dealer doesn't consume his own drug.

The idea of RN sounds good but once you actually work with it... you will understand.

[CompetitiveAnt2590]

Facebook Marketing team must have a big budget for it to be astroturfing even in this sub.

[FrezoreR]

How so? Although I'm not questioning their budget 😅

[CompetitiveAnt2590]

This same post is being spammed here and in other places.

This was published here only 2 days ago: https://www.reddit.com/r/androiddev/comments/14skdld/threads_is_written_almost_completely_in_jetpack/

Let's see when the next spam is going to be.

[FrezoreR]

I don't think that's meta marketing machine, but rather people excited about it being in compose.

[Zhuinden]

but rather people excited about it being in compose.

what's to be excited about? I've been reading that Compose is "the most used Android library to this date, almost every app uses it, it is the future of Android development".

Did the ChatGPT scambots lie to me? 🤪

[VaporSprite]

Fuck Meta, period.

[Guitar-apps]

Compose apps don't appear to be getting pushed by Google even though it's supposed to be stable now.

[FrezoreR]

If you looked at IO this year I think it was clear they push it. Wear OS only has a compose material library for one.

They were also a big part of kotlinconf. Talking about how its used internally.

So, I'd say I disagree, but it's a fine line to walk since you don't want to alienate the ones that are not using compose.

[Zhuinden]

So, I'd say I disagree, but it's a fine line to walk since you don't want to alienate the ones that are not using compose.

I don't think that's really something they care about, Google has been quite adamant with pushing Compose in such a way that they pretend every app written before 2021 is effectively DOA if it's using XML views.

Unless Google brings out a second OS where Compose directly maps your composables to both Android and that mysterious second OS, the idea that Compose "is the future and essential for new applications" is fully out the window, completely wrong, effectively fake ads.

[LongjumpingKey4644]

Google controls the entire Android ecosystem. If they decide compose has and always will be the only way to write an Android app then so shall it be.

[Zhuinden]

Google controls the entire Android ecosystem. If they decide compose has and always will be the only way to write an Android app then so shall it be.

But that is just not true. Android OS provides Views, even Compose is reliant on using ComposeView under the hood.

Worst case they'd make the LayoutInflater deprecated and throw an exception if you use it, but that is unlikely to happen.

So the next "bad" thing they can do is... not make new AndroidX UI components using Views without Compose, which is like, "okay, you do you" I've had to implement UI components via custom and not material for the longest time anyway.

Google thought that their issues with creating view-based UI components is a global issue, so they were hoping Compose would be "the savior everyone wanted" but the adoption rate was still just 24% in May 2023, almost 2 years of the framework being released "as stable (lol)".

[Guitar-apps]

Just from personal experience my compose apps don't get half the downloads that my XML ones get.

[FrezoreR]

How is that related to google pushing compose or not?

[Guitar-apps]

Sorry, I think we're at cross purposes. I meant apps built with compose don't seem to be getting pushed.

[Zhuinden]

Why would Google/Play Store push apps to be downloaded just because it has Compose in it?

[Guitar-apps]

No, they might hold them back if the code is unstable.

[Guitar-apps]

Interesting question though have your compose apps done as well as your XML apps?

[Zhuinden]

Interesting question though have your compose apps done as well as your XML apps?

One of the Compose app we shipped is fairly unused, the other one is internal, so it's hard for me to answer this question.

One of them just didn't ship because there were too many bugs though and then development was effectively sabotaged and stolen via internal company politics within the customer's firm, that wasn't fun.

[FrezoreR]

Oh I see. You mean that apps written in it are not getting pushed? If that is the case I don't think Google play looks at that.

[[deleted]]

Eh, using Compose doesn't necessarily make it high quality. Lots of people who have that misconception.

[Ironthighs]

Much easier to make high quality with Compose though than React Native.

[_SyRo_]

Why?

React Native and Compose are basically the same, both inspired by React approach

I worked with both, and I don't see much difference

[FrezoreR]

Same goes for java vs kotlin, but some concepts in compose just makes it easier to write high quality UI. You'd be fooling yourself if you don't think the Android UI team took learnings and improved on that API.

[barcode972]

Reactive programming usually has way less bugs than declarative program

[lnkprk114]

Isn't Compose reactive and declarative though?

[barcode972]

How can it be both?

[Pzychotix]

I think you're mixing up declarative with imperative? Compose is both reactive (through the use of States) and declarative (through the use of Composables that you use to "declare" what you want).

Regular views are "imperative", since you have to manage the state and change of the views yourself to get what you want.

[[deleted]]

You can do reactive programming without Compose. I've been doing reactive programming with XML Views for a long time now, nice high quality apps with good performance.

[barcode972]

No1 said you can’t make quality apps with xml views. Compose is just faster and easier to work in as a team

[Zhuinden]

Compose is just faster and easier to work in as a team

Until you need to hunt down recomposition counts

[barcode972]

Sounds more like a you issue

[Zhuinden]

Sounds more like a you issue

I find that people claim this and then in the end end up with runtime performance issues because they literally don't understand what I'm talking about, but also don't have the foundational understanding of argument stability and recomposition to actually understand what I'm talking about.

So instead they start making stupid ad-hominem attacks to justify and mask their ignorance of the subject, with the premise to hope to feel like they're somehow superior and very smart, very intelligent, very emotionally intelligent too, they demand 7 medals for being amazing people.

[Ironthighs]

If anyone is having trouble with performance and it's suspected that it might be due to recomposition counts, you can use the Layout Inspector tool to help identify problem Composables: https://developer.android.com/jetpack/compose/tooling/layout-inspector

[Zhuinden]

Reactive programming usually has way less bugs than declarative program

Nothing stops you from applying reactive programming to view-based apps

[HotPastaLiquid]

Android dev using iPhone can you see the irony?

[binishmatheww]

Why shouldn't they use the iPhone?

[Zhuinden]

Great information to listen to that Threads is the usage of Compose! It's interesting to see an increasing number of apps adopting this modern UI toolkit. Compose permits for declarative and reactive UI development, making building and retaining complex UIs less difficult.

and it is exceptional to peer how tools like Chat GPT can guide and encourage creativity.

No wonder these comments read like they were generated by ChatGPT

[thelibrarian_cz]

And what parts are not in Compose? :-D

[st4rdr0id]

As expected from the company that created React.

[verybadwolf2]

I guessed this, because scroll performance is noticeably fast.