Yes. They don’t think hard enough before they do things or put enough care into doing it. That’s apparent in their product lineup, support and reliability.
Nah, the first version will be great but not revolutionary. After a few iteration it will get really great to the point that it is competitive with Apple and with even Apple borrowing ideas back.
But then they'll lose focus and after a couple more iterations it will get abandoned and left for 5 years before it is axed. And 3 different chips will pop up in its place which are similar but incompatible.
While it looks like copying Apple, it doesn't necessarily mean this is a bad idea. Google did produce TPUs so this isn't theirs first rodeo. Also Apple is using ARM so whatever are their improvements, others can potentially match. Of course the execution matters, but if the current trend continues it may well be an existential threat to Android and by extension, Google.
Also, presumably this whole process didn't start this month. Developing a chip takes time. This article makes it sound as though this is well on its way to production.
I searched HN; nobody had submitted this story from any source to the best of my knowledge. First I heard about this Project Whitechapel was today when Dave2d mentioned it in a video about upcoming next gen (2021) smartphones, props to Dave: https://www.youtube.com/watch?v=U7HxYOaFr88 – couldn't believe it hadn't been discussed here.
this big advertisement company has no business developing chips. With all due respect to engineers working on those, one little tweak in search result ranking or another smart sneaking behind unaware user earn them lot more than any new chip however good will ever. from pure business perspective, there's no a single one real intensive to develop such chips.
Also, they have failed to develop far less complex chips in the past, despite very competent teams. There will be a failure this time around too.
I'd be shocked if this ever made it to production.
I'd be more shocked if they did this for 2 generations of pixels.
The problem with vertical integration is how fast you can be obsolete by competitors. You only need 1 competitor to make a better product and your internal Engineers are going to be begging for it.
Unlike Apple customers, the rest of the population is sensitive to performance and cost. If Google can't compete people move on.
Edit- Samsung is not a flagship company, their high pricing has nothing to do with performance. At best they are mid tier.
Maybe a logical progression for the TPU chips and having on-board cores to manage the TPU side of things for performance does make sense and if they can scale this for other products, then why not. Given the whole mobile CPU performance caught up and power usage become the biggest saving area on the table PR financially as well as direct financial savings. Then I'd hazard a educated stab that maybe what is afoot here.
However it pans, the Linux kernel is sure going to see some nice ARM optimisations over the comming years out of all this drive.
Apple has a first class in house design team. Google is subbing out so they don't get any long term benefit from an experienced employee base and they have to share a slice of the extra profit with someone else in addition to paying larger license fees to ARM than Apple needs to.
This is probably just a bow shot to Qualcomm to get a better deal out of them the same way PC vendors threaten to switch to AMD to squeeze Intel.
Qualcomm has been price gouging while limiting features from each new release (for example, the new 888 doesn't have AV1 decode support... WTF!)
This is google forcing them to up their game if they want to keep playing.
Will google keep doing this? Probably not (IMO). Rather, it's likely just a demonstration of "Hey, we don't need you, so straighten up!"
That being said, if Qualcomm ignores them (since Pixel isn't a major player in the phone market) google may keep producing their own chips.
Another interesting aspect here is that Google may decide that they don't want to keep paying for the ARM licenses. This is an avenue for them to start getting RISC-V as a first class Android citizen.
I actually think there's a pretty easy way around this for Google. They could create a ARM -> RISC-V translation layer. That works well because RISC-V already has a very limited instruction set. In order to make things fast, you don't need to do a lot of fancy transforms.
The issue with doing the same ARM->x86 translation is the x86 instruction set is vast and to get the best performance requires you effectively use those instructions. That requires you to merge instructions that you wouldn't have merged (think of things like the lea instruction).
There's less of an instruction impedance mismatch going from ARM to RISC-V.
Interestingly, I think going from x86->ARM or RISC-V would present less of a performance problem. That's because most of the work would be splitting one instruction into many. The evidence of this is the x86->IA-64 which resulted in something like a 10->20% performance loss vs a natively compiled IA-64.
> Unlike Apple customers, the rest of the population is sensitive to performance and cost. If Google can't compete people move on.
This is an odd phrasing: Apple's pricing isn't higher than the competition — flagship Android phones frequently cost noticeably more — and when it comes to performance it's very hard to beat the $400 iPhone SE2 at any price.
Vertical integration is what allows Apple to be ahead on both price and performance. The only way Google is matching that is with a strong long-term commitment to make similar investments. Apple will falter at some point but after years of ignoring the basics Google won't be able to take advantage of that — especially since at this point they're chasing Apple's previous generation so it'd take an extended sag for Google to catch up much less surpass with their current half-hearted strategy.
> Vertical integration is what allows Apple to be ahead on both price and performance.
I don't know about that. The processor is the main thing they have vertically integrated, right? And if I go look at a flagship like a Galaxy S20 Ultra 5G I see a BOM of $57 for the processor. (It does have a hideously expensive modem for 5G but it didn't need to have that.)
Consider the knock-on effects though - that processor isn't necessarily optimising the things Samsung might want, nor is Android, which costs them more in other ways (I'm particularly thinking of the fact that Android phones seem to have to include a lot more RAM than iPhones, so that's another chunk of BOM).
They control the entire system on a chip — remember how long it was before Android devices started to have the security features which Apple introduced in the iPhone 3GS? That took Google getting phone vendors to get the CPU vendors to all work together, whereas at Apple that's a couple of teams all working on the same product with the same incentives to make it succeed.
With Apple, it was security theater. With multiple vendors working together, it has to actually work to get everybody on board with putting in the resources.
There's also the OS and other aspects of the walled garden that you must choose between an iPhone and some other flagship. I personally select for some perceived optimization of attributes such as "has Android" and "has good value for price" among other things. If Apple made a phone like that I might buy one. Unfortunately, all of their phones have iOS.
The wall is pretty low, when you download an apk and open it, it asks you if you want to unlock the gate. In earlier builds of Android, you had to find the setting yourself, which was at least a little harder.
Nearly 100%, but you're comparing against the wrong devices. When I run a Linux router, I am not choosing at random from all the vendors. It's the same for my phone. I choose which one to use on purpose. Not only can I install my own apps, but I can install my own system as well. This lets me run devices from 2013 on the latest version of Android.
Answers below until I am no longer rate limited:
> Sure but almost nobody can do that because they didn’t make the same careful choice as you did.
What does that have to do with anything? Just because all iOS devices are bad and many Android devices are bad doesn't mean all devices are bad. I choose from the good devices.
> Also, you routinely make unsupported claims
Show me one unsupported claim I have made.
> you are going to say nearly 100%, you’ll need to show a source.
I have literally never seen an Android phone that does not allow sideloading. I have heard of many that do not allow unlocking the bootloader, but sideloading is standard. I can't provide a source because the idea that an Android phone would not allow sideloading is so absurd that nobody would bother explaining why it doesn't exist.
> it contradicts what others say when I suggest Android is an open alternative to iOS.
What have others said?
Edit 2 for the second post:
> Usually when I bring up sideloading as a reason why people should choose Android if they don’t like the restrictions of iOS, people claim that it is too hard for regular users to do because of the configuration required.
The OS takes the user to the settings checkbox to check. This has been true for as long as I can remember.
Sure but almost nobody can do that because they didn’t make the same careful choice as you did.
Also, you routinely make unsupported claims, so if you are going to say nearly 100%, you’ll need to show a source.
I’m happy to accept this as true by the way - I would like Android to have this level of openness, but it contradicts what others say when I suggest Android is an open alternative to iOS.
I’m not going to respond in general to your edited comment, since it is not what I replied to originally.
Editing a comment to get round a rate limit creates a misrepresentation of the thread your interlocutor was responding to.
I don’t mind waiting for you to be allowed to respond in the normal way.
Nobody is talking about Android phones ‘not allowing sideloading’.
The question is only about what percentage of phones allow a sideloaded app to be installed from the web just by responding to a dialog, rather than changing a configuration.
Usually when I bring up sideloading as a reason why people should choose Android if they don’t like the restrictions of iOS, people claim that it is too hard for regular users to do because of the configuration required.
I was responding to a comment which said this had changed and now it is much easier.
I don’t believe nearly 100% of users have this experience yet, but I am curious to know what the number actually is, because it matters for developers.
> people claim that it is too hard for regular users to do because of the configuration required.
Who are these people? The error message has always linked to the settings checkbox to allow installing the app. The only thing that has changed is which checkbox it links to because the settings for installing apps from unknown sources have changed. Here is a video of the way it used to be. I know that you're going to say that you don't believe video proof, but this is all I have for you.
I don’t need video proof for this. Other people are confirming it.
‘These people’ are generally replying to the suggestion that if people don’t like iOS because it it doesn’t allow sideloading, then why not buy Android?
From what you and others are saying, sideloading may not even be an appropriate term - you make it sound like you can just install software from the web on Android directly.
I have no stats. Only my own annecdotal experience.
On Android 2.x, I remember apk download installs just failing, until you changed the settings; but everything else has been pretty easy. A Samsung KitKat phone I was using recently was even nice enough to have a 'allow just this app, or let it be wide open' checkbox.
About the only thing I sideload that's not on the play store is rooting toolkits, but sometimes it's convenient to get the APK another way (Google Play requires logging in to Google, which is hard to undo, for example)
This is cool, and much better than the impression I had from reading comments here.
I have frequently read that sideloading is impractical as a way to sidestep the store on Android when delivering software to consumers, but that sounds like it’s just wrong.
I don't think it's impractical, but it is more difficult.
Some users will be scared away by the warning text, and it's hard to prepare them with example dialogs, because there's such variation.
You'll need to build your own auto-update service, which (probably?) can't do delta updates like Play can. If you have a lot of users, and you can't dither the downloads[1], you may have a huge download peak.
If you have native libraries, off store downloads need to contain all the versions, but on store only downloads the arch appropriate ones.
If you make apks for download, people will archive them and make them available to others, even after they're obsolete. This happens with play store too, of course.
People who download your apk directly are also likely not to have play libraries or access to google etc. If your app depends on those things anyway, you're going to be missing functionality, or have to implement fallbacks for say, maps and push, etc.
People are still going to look for your app in the play store, so you probably want it there too; at least if it's not something that Google will disallow.
[1] Android really likes grouping background timers, so you will probably experience peaks at local X:00 for all of your users. And local X:00:08 for your users on networks with slightly off clocks
> Sideloading doesn’t refer to installing apps you have developed yourself.
If you can do one, you can trivially do the other. It's effectively the same feature to the end user. I develop my own apps and upload them to cloud storage to install them on all my devices.
> You can install your own app on your own iOS device without using the store, but you cannot distribute to end users.
My own devices and the devices of my friends and family are end users. I do not have to connect the devices to my computer. On iOS, you cannot do this without paying Apple yearly unless you want to deal with reinstalling every week.
> The two things are not one and the same.
They are enabled by the same mechanism. If you have one, you automatically have the other.
This is called “moving the goalposts”. It’s a kind of fallacy.
You said: “Hundreds. I develop apps for my own devices. This is supposed to be a forum for technologists.”
I said: Sideloading doesn’t refer to installing apps you have developed yourself.
You said: If you can do one, you can trivially do the other.
This is clearly not true. You can install apps you have developed yourself on your own iOS devices for free, but you cannot distribute them. They do expire, but you can certainly install and use them on your own devices.
So then you changed the goalposts to “My own devices and the devices of my friends and family are end users”.
Which is not what you originally said. You originally said “for my own devices”.
We agree that sideloading is about distributing software to end users. Not just your own devices.
The two are not one and the same mechanism. The fact that you had to change your qualifier shows this.
Apple computers have always been slower and more expensive than their non-Apple counterparts, and this gap has been larger recently due to sourcing from the struggling CPU vendor and the struggling GPU vendor. Worse, the software adds a 30% performance penalty on top.
Which is why I provided a link to show it. Whenever I see IntelliJ IDEs on Macs, they seem so sluggish, and the benchmarks in that link show that Java2D is several times slower on MacOS on the same hardware.
iOS is even worse, taking vastly superior hardware and still managing to perform worse on standard productivity tasks.
The post doesn’t substantiate the claim: “The software adds a 30% performance penalty on top”. It shows performance on an extremely narrow test which clearly doesn’t represent general performance.
As to your claim about iOS. There is literally nothing to substantiate it.
> The post doesn’t substantiate the claim: “The software adds a 30% performance penalty on top”.
From the link I posted: "Ubuntu 19.10 meanwhile had a 29.5% advantage over Apple macOS..."
Ubuntu 20.04 is faster still on that set of benchmarks, and ClearLinux has a 10% performance increase on top of that.
>It shows performance on an extremely narrow test.
No, it includes a very broad range of tests. I just highlighted one of them, on which MacOS performs particularly poorly and which affects software a lot of us use.
> As to your claims about iOS. There is literally nothing to substantiate it.
I gave you three links to substantiate it. It also matches my own experience.
These technologies are long deprecated on Apple platforms.
It’s completely unrepresentative. But sure, if you rely primarily on Java or OpenGL for your workloads, I agree that a Mac isn’t the right choice for you.
It’s a lie to say “The software adds a 30% performance penalty on top” based on these results. It doesn’t.
If you have something credible to link to about iOS performance being slower, I’m interested, but I’m not going waste time watching YouTube videos that nobody else is going to bother with.
If it’s that bad, you’ll be able to find some credible analysis in writing. I’m guessing you can’t.
> These technologies are long deprecated on Apple platforms.
This doesn't matter to the user, who is still using apps like IntelliJ IDEs. To the end user, this is a problem with MacOS, which does not allow GPU vendors to update their OpenGL drivers. Meanwhile, Ubuntu has far superior OpenGL performance and superior Vulkan performance on the same hardware.
> It’s a lie to say “The software adds a 30% performance penalty on top” based on these results.
You keep saying that, but you haven't explained why. MacOS is also twice as slow on git operations according to the benchmarks. Java2D and git are software that people use that are multiple times slower (not merely 30%) on the same hardware.
> I’m not going to watch YouTube videos.
Then I'll post text summarizing them. Android on midtier previous generation phones launches apps to interactivity faster than iOS running on latest generation hardware, and this has been the case for about ten years now. There are hundreds of videos on YouTube substantiating that.
Edit to respond to below comment due to rate limiting:
> YouTube videos, however many, are not a credible source of operating system performance claims. You can find YouTube videos supporting flat earth theories or that Obama is a lizard alien.
The YouTube videos doen't say that Android is faster. They show that Android is faster. You seem to not understand the difference between people claiming things are true and people showing things are true.
It's the same with the 30%. I showed a suite of benchmarks where MacOS is 30% slower on average. It was many times slower on a few specific benchmarks I called out.
> If you are a heavy Java or OpenGL user, don’t by a Mac.
I'm glad we can agree on that. You forgot heavy git users.
Edit 2:
> It creates a dishonest impression of the thread.
How does replying with edits create a dishonest impression of the thread when I very clearly indicate which comment I am replying to? If you would like to respond normally, there is a very easy way to enable that. Simply upvote my comments to disable the rate limiting.
If you are a heavy Java or OpenGL user, don’t buy a Mac.
If you are running a git server farm, don’t use macs. If you are a developer using Git, you’ll be just fine.
These just aren’t representative of most people’s experience.
It’s a lie to say the software is 30% slower.
It’s even a lie to say it’s 30% slower for an IntelliJ user.
It’s only 30% slower on a narrow benchmark.
YouTube videos, however many, are not a credible source of operating system performance claims. You can find YouTube videos supporting flat earth theories or that Obama is a lizard alien.
If you can’t find any article anywhere substantiating your claim, I think we can conclude that it’s not supported by evidence.
If it was that bad, a reputable site like ars, or anandtech would have shown it.
I gave you a source. The sluggishness is something I notice when I use MacOS.
> If it was that bad, a reputable site like ars, or anandtech would have shown it.
It is that bad. Hundreds of YouTubers have shown it, and you can do it yourself to confirm. I have friends who have iPhones. The launch times are noticeably slower.
I'll even give you my speculation for why this is the case in order of impact:
1. Android's zygote based process initialization.
2. Developers optimizing for the $50 Android phones in the long tail.
There are a set of cold boot launch times which can be shown to be slower in a video, but this is not a metric of software performance nor does it impact users.
You’ve attempted to use a set of YouTube videos to justify a false statement.
As I have said before - if iOS was slower than Android you’d be able to find a reputable source to show it through analysis, not some staged YouTube videos looking for clicks.
I showed you that it is, and you keep saying that it isn't. I even gave you some examples that are more than 100% slower.
> There are a set of cold boot launch times which can be shown to be slower in a video
That's what I said they were. You kept not believing me even though I showed proof. Now you say that it doesn't matter. It is in fact the biggest thing that matters for productivity apps, aside from UX, where Android wins by a bigger margin due to smart replies and other actions in notifications.
> You’ve attempted to use a set of YouTube videos to justify a false statement.
You keep saying that, but you've just agreed in this comment that my statement was wholly correct.
What you said is this: “Apple computers have always been slower and more expensive than their non-Apple counterparts, and this gap has been larger recently due to sourcing from the struggling CPU vendor and the struggling GPU vendor. Worse, the software adds a 30% performance penalty on top.”
This is a false statement. The YouTube videos do not change that.
Moving the goalposts to “the most important thing for productivity apps”, doesn’t change the original statement.
Taking aside the moved goalposts, even your new statement is false. Cold boot time for productivity apps is not the most important thing for productivity apps, since cold starting a regularly used app is rare.
The fact that you know these videos only show a rarely occurring situation, shows that you know you were lying when you made the original statement: “Worse, the software adds a 30% performance penalty on top”.
Also I said: “There are a set of cold boot launch times which can be shown to be slower in a video”
To which you said: “That's what I said they were.”
If this is true, you’ll be able to link to the comment where you said you were talking about cold boot launch times that precedes mine.
The pattern here is that you make a general statement which is completely false as written, and then attempt to change the goalposts and justify a much narrower statement that doesn’t actually support what you originally said.
> This is a false statement. The YouTube videos do not change that.
I never said they did. Can you not read? How many straw men do I have to burn down to have a discussion with you? The substantiation comes from an article with benchmark results.
> Moving the goalposts to “the most important thing for productivity apps”, doesn’t change the original statement.
I made two separate claims: one that MacOS is slow and one that iOS is slow. There are two separate goal posts that I put up, and neither one has moved. It's like I'm arguing with a post.
> If this is true, you’ll be able to link to the comment where you said you were talking about cold boot launch times that precedes mine.
I said it is faster at launching apps to interactivity. This is for cold boot and not. The apps launched after the first in each video are long after cold boot.
Your reading ability is so low that it is useless to carry on a discussion with you. No wonder you use Apple products. You're the rube who actually believes Apple's marketing.
> I made two separate claims: one that MacOS is slow and one that iOS is slow.
No. That’s a new statement you are making now.
You made this claim:
“The software adds a 30% performance penalty on top.”
Which is false, regardless of which platform you are talking about, and not supported by the links you shared, which in both cases were corner cases that cannot support a general claim like this.
As I have said before, if this claim were true, you’d be able to find a reputable source, e.g. Ars or Anandtech.
It's hard to imagine Apple's brand maintaining its luster without good performance, and when Apple sells over 1B phones, it's hard to imagine that price-efficacy wasn't a huge part of the package.
On the other hand, Androids have a reputation to get somehow jankier or sluggish over time, and that surely must affect its brand and overall standing for consumers.
I understand there are arguments about why this is a good idea, but Apple is settling, which tells me a fair amount about how Apple thinks those arguments would land in court.
That might have been true for a couple of years if you just compare pure computing power, as soon as you factor in build quality and compared it to Thinkpad X1s, XPS & Co you were in similar price ranges again. Or if you don't care about build quality, another classic is the high-res displays (and software support) which took the competitors years and some might argue that they're still not there.
Oh and there was also a couple of generations where Apple had pretty much kind-of exclusivity on Intel's newest CPUs and they were really only available in MacBooks for the first few months.
Yeah, all stuff that sucked. There is even more, Staingate, Bendgate, ... Never said Apple is flawless :) You think the comparable offerings from Dell, Lenovo or HP are flawless? Oh I have news for you.
You know what, if you look close enough, "they all suck".
Not for comparable quality, you weren't. The prices varied depending on features but it wasn't twice as much unless you failed to control specs (I remember forum posters accusing everyone of being fanboys when they came up with a number like that by comparing, say, an Apple device with an SSD to something with a previous-generation processor and spinning metal drive). If you're buying comparable quality you get fairly comparable cost.
Apple has a 10 year lead time on Google for running OSes on in-house Silicon. If there is no intention to compete with Qualcomm, how are they going to get the economies of scale problem down to where the chips are affordable + performant? The volumes of Chromebooks/Pixels sold in a week vs. iPhones in a week is stark.
"X has an insurmountable lead" almost always turns out to be wrong. You could have made the same argument with x86. Intel/AMD used to at least have the argument that they had vertically integrated because they not only designed the chips, but also designed the fabs.
Apple is a fabless designer, other vendors have access to TSMC as well, as long as they have space capacity. Realistically, other ARM vendors are about 2 years behind. A Snapdragon 875 scores the same as an Apple A12 on Single Thread Geekbench.
On GPU and TPU, Apple isn't that far ahead at all. TPUs are relatively simple devices, and the Snapdragon 888 already has almost double the A14 performance in TOPS on paper. GPU wise, the A14 (PowerVR derived) GPU is roughly equivalent to a 2016 era NVidia 1060. AMD's RDNA2 based cores for SOCs are likely more powerful and more capable (e.g. raytracing acceleration)
Much is made of how far Qualcomm is behind Apple, but like with AMD and Intel, Qualcomm has a wider market focus to address. Apple sells only a few SKUs, Qualcomm needs to make chips for a much wider array of demands, and so they're a jack of all trades, master of none. In much the same way, AMD and Intel have desktops and enterprise vendors to satisfy, including people running SMP systems. Does the M1 support multiple M1 SMP? Does it support ECC? The other vendors are kind of hamstrung by trying to make one architecture that pleases too many markets at once.
"Qualcomm’s 25% generational boost is also less than Arm’s advertised 30% as the new S888 continues to use a 4MB L3 cache for the CPU cluster, versus Arm’s envisioned 8MB configuration for a high-end 5nm SoC with the new X1 cores. Qualcomm explained to us that this was simply a balance between cost, implementation effort, and diminishing returns of a higher cache configuration design."
Basically, Qualcomm needs to worry about what their customers are willing to pay for the chip and how much work it takes to integrate. Apple doesn't, if need be, they can bump the price for a more expensive SOC, Qualcomm Android vendors can't.
25% CPU performance uplift and 30% GPU performance uplift for the 888. the A14 gets 1583 Single Thread in Geekbench, the 888 will likely turn in a final Single Core perf between 1300-1450, only 9% less than the A14. The situation is the same for multi-core, roughly on par, and on Antutu, the Snapdragon 875 beats the A14 substantially, and wins on several 3dMark tests.
Apple does not have an insurmountable lead over the other vendors in terms of SOC, I'd argue that their primary advantage right now is their software has always been better. In particular, WebKit's JIT for ARM does a lot better than V8 for ARM, and Android Dalvik does not produce code that runs as well as LLVM on Swift (plus there's generational GC vs ARC+refcounting).
Otherwise, a 9% CPU advantage in single thread performance is nothing to write home about.
I don’t get how you can look at Apple’s mobile offerings, which have been years ahead of all the Android competition, and come to the conclusion that Apple customers don’t care about performance.
I’d say Apple’s customers are far more sensitive to performance than Google’s given what Android users have been willing to put up with (e.g. flagship SoCs that are years behind what’s in last year’s iPhones). If you factor in broader aspects of performance (e.g. Face ID, fingerprint unlock speed) it’s clear that the _only_ thing most Android users care about is cost. I’m not saying this to diss them, I just think the Android manufacturers owe it to their users to actually produce competitive hardware and software.
P.S. if you factor in longevity, Apple products are usually cheaper, too.
> Unlike Apple customers, the rest of the population is sensitive to performance and cost. If Google can't compete people move on.
Maybe they meant both independently. As an example:
- A friend of mine just upgraded out of his iPhone 6. Until recently performance and storage seemingly just weren't that important to them.
- Another friend of mine will just buy iPhones, no matter the cost.
Both of these friends stick with Apple because they like and care about other things about the ecosystem more so than performance or cost (independently), whereas OP was perhaps implying that Android users tend to care more about "performance to cost ratio" since they could as well just buy a different phone from another maker and get the same Android experience. This of course, in the context sticking with one phone maker or another.
As someone who upgraded this year from the 6 to the SE 2, I held out not only because I like the ecosystem, but also because I'm not shelling out almost one grand for a phone. The SE hit the sweet spot, so I ordered one the first day it came out.
I wish I had waited and gotten an SE 2, especially because Touch ID is way more convenient than Face ID nowadays that one's often wearing a face mask haha
It's not about features or performance for most of the population, who are light users. Most users of anything are not power users and modern smartphones are good enough for casual usage, since 2016 or so. Even mid range Android phones.
In the US iPhones are entrenched because of network effects (iMessage or whatever it's called) plus the Apple ecosystem. In the rest of the world where this is less the case, iPhones are a status symbol. Not even expensive Android phones have the halo iPhones have, especially in poorer countries.
Yes, people will enjoy the extra performance or extended software support, but that's not why they will buy them. I doubt 99% of regular users even know about those aspects.
The smart move for Google here would be to debut their own chips in Pixels, but then sell the chips to other phone manufacturers to use in their phones. Assuming the chips provide enough raw performance and interesting hardware acceleration, that would make it a reasonable business for Google to stay involved in.
> Samsung is not a flagship company, their high pricing has nothing to do with performance. At best they are mid tier.
Their high pricing has to do with the slew of software and hardware features they include, many of which are executed at least reasonably well and later trickle down to mid-tier brands like Google's Pixel line or more conservative high-end brands like Apple. For instance: DeX, more flexible fast USB C and wireless charging than most manufacturers, pen/remote support with in-device charging and corresponding apps, Samsung Pay with magnetic stripe emulation, etc.
Samsung isn't focused on raw computing power, because they largely depend on the same chips as most of their manufacturers, but if you've used a newer Galaxy S/Note device the level of hardware polish and random "gimmicky" but occasionally useful features far outpaces a Pixel or similar.
Disclaimer: I currently own a Pixel (because there are other things that Google competes on) but last owned a Note 9.
Well, Exynos SoCs are widely panned as garbage. People in Europe regularly import HK versions of phones to get the Qualcomm version.
Second, my understanding is they don't have CDMA support, which is still relevant in the US. So they either use Snapdragons, or pay Qualcomm for the patents and then go make a new SoC. I guess it's easier to just pay Qualcomm for the Snapdragons.
Wow, that's wild. My first cell phone had brand-new (at the time) EVDO support. It was awesome, you could download songs, use WAP, etc. I can't believe I've actually seen the beginning and end of a full generation :)
I also still can't believe the iPhone launched without 3G support!
1. Samsung Silicon uses Samsung Foundry, there is a yield / quality / capacity / performance issue.
2. Qualcomm patents on CDMA and having much better modem.
3. Qualcomm's GPU being better than ARM Mali and CPU being better than Stock ARM ( Samsung ) implementation.
But All of these are changing and Samsung wants to succeed in these areas. Foundry is catching up a little bit, so may be a little more than 1 year behind in TSMC in terms of league edge and capacity. ( Forget about their goals and Roadmap as well as investors notes they are even worst than Intel ). They have signed a partnership agreement with AMD bringing RDNA to Mobile. Their Modem is improving with each generation, and the patents issues has been sorted out recently. ( Which is pretty much the same deal as Apple )
It will take some time. 2021 Exynos may be a little too early so 2022 seems like a safe bet. Although Qualcomm isn't sitting still either.
It’s not just about copying Apple or reducing costs. It’s about the benefit of SoC integration, and Chrome/Android is unique enough in this regard to get a lot of benefit versus discrete components.
Frankly I'd be happy if they stopped using those garbage POLED panels from LG. Three years and every single one of them has a green tint to the bottom half of the screen.
I have to wonder what would be the outcome, given what happened to their previous hardware efforts. I just shared this in a private chat, and the first reply was "will they also stop working after 18 months?"
115 comments
[ 4.3 ms ] story [ 75.3 ms ] threadGoogle: Write that down! Write that down!
But then they'll lose focus and after a couple more iterations it will get abandoned and left for 5 years before it is axed. And 3 different chips will pop up in its place which are similar but incompatible.
Apple uses the ARM ISA but entirely custom cores, so this is like saying "AMD is using x86_64, so Intel can match them".
The G3 and G4 chips were much faster in their time than comparable Pentiums, as well.
The M1 chip is faster, currently, but it's not invincible.
Another story from April with a few more details: https://www.xda-developers.com/google-is-working-on-its-own-...
Do you have anything else you can link in regards to the work they’re doing in building out their own chips? Would love to read more about this.
I'd be more shocked if they did this for 2 generations of pixels.
The problem with vertical integration is how fast you can be obsolete by competitors. You only need 1 competitor to make a better product and your internal Engineers are going to be begging for it.
Unlike Apple customers, the rest of the population is sensitive to performance and cost. If Google can't compete people move on.
Edit- Samsung is not a flagship company, their high pricing has nothing to do with performance. At best they are mid tier.
However it pans, the Linux kernel is sure going to see some nice ARM optimisations over the comming years out of all this drive.
This is probably just a bow shot to Qualcomm to get a better deal out of them the same way PC vendors threaten to switch to AMD to squeeze Intel.
Qualcomm has been price gouging while limiting features from each new release (for example, the new 888 doesn't have AV1 decode support... WTF!)
This is google forcing them to up their game if they want to keep playing.
Will google keep doing this? Probably not (IMO). Rather, it's likely just a demonstration of "Hey, we don't need you, so straighten up!"
That being said, if Qualcomm ignores them (since Pixel isn't a major player in the phone market) google may keep producing their own chips.
Another interesting aspect here is that Google may decide that they don't want to keep paying for the ARM licenses. This is an avenue for them to start getting RISC-V as a first class Android citizen.
The issue with doing the same ARM->x86 translation is the x86 instruction set is vast and to get the best performance requires you effectively use those instructions. That requires you to merge instructions that you wouldn't have merged (think of things like the lea instruction).
There's less of an instruction impedance mismatch going from ARM to RISC-V.
Interestingly, I think going from x86->ARM or RISC-V would present less of a performance problem. That's because most of the work would be splitting one instruction into many. The evidence of this is the x86->IA-64 which resulted in something like a 10->20% performance loss vs a natively compiled IA-64.
This is an odd phrasing: Apple's pricing isn't higher than the competition — flagship Android phones frequently cost noticeably more — and when it comes to performance it's very hard to beat the $400 iPhone SE2 at any price.
Vertical integration is what allows Apple to be ahead on both price and performance. The only way Google is matching that is with a strong long-term commitment to make similar investments. Apple will falter at some point but after years of ignoring the basics Google won't be able to take advantage of that — especially since at this point they're chasing Apple's previous generation so it'd take an extended sag for Google to catch up much less surpass with their current half-hearted strategy.
I don't know about that. The processor is the main thing they have vertically integrated, right? And if I go look at a flagship like a Galaxy S20 Ultra 5G I see a BOM of $57 for the processor. (It does have a hideously expensive modem for 5G but it didn't need to have that.)
https://www.wired.com/2009/07/iphone-encryption/
The facts suggest it is Samsung customers (and perhaps a few other brands) who care more about the brand than performance and cost.
Answers below until I am no longer rate limited:
> Sure but almost nobody can do that because they didn’t make the same careful choice as you did.
What does that have to do with anything? Just because all iOS devices are bad and many Android devices are bad doesn't mean all devices are bad. I choose from the good devices.
> Also, you routinely make unsupported claims
Show me one unsupported claim I have made.
> you are going to say nearly 100%, you’ll need to show a source.
I have literally never seen an Android phone that does not allow sideloading. I have heard of many that do not allow unlocking the bootloader, but sideloading is standard. I can't provide a source because the idea that an Android phone would not allow sideloading is so absurd that nobody would bother explaining why it doesn't exist.
> it contradicts what others say when I suggest Android is an open alternative to iOS.
What have others said?
Edit 2 for the second post:
> Usually when I bring up sideloading as a reason why people should choose Android if they don’t like the restrictions of iOS, people claim that it is too hard for regular users to do because of the configuration required.
The OS takes the user to the settings checkbox to check. This has been true for as long as I can remember.
Also, you routinely make unsupported claims, so if you are going to say nearly 100%, you’ll need to show a source.
I’m happy to accept this as true by the way - I would like Android to have this level of openness, but it contradicts what others say when I suggest Android is an open alternative to iOS.
Editing a comment to get round a rate limit creates a misrepresentation of the thread your interlocutor was responding to.
I don’t mind waiting for you to be allowed to respond in the normal way.
Nobody is talking about Android phones ‘not allowing sideloading’.
The question is only about what percentage of phones allow a sideloaded app to be installed from the web just by responding to a dialog, rather than changing a configuration.
Usually when I bring up sideloading as a reason why people should choose Android if they don’t like the restrictions of iOS, people claim that it is too hard for regular users to do because of the configuration required.
I was responding to a comment which said this had changed and now it is much easier.
I don’t believe nearly 100% of users have this experience yet, but I am curious to know what the number actually is, because it matters for developers.
Who are these people? The error message has always linked to the settings checkbox to allow installing the app. The only thing that has changed is which checkbox it links to because the settings for installing apps from unknown sources have changed. Here is a video of the way it used to be. I know that you're going to say that you don't believe video proof, but this is all I have for you.
https://youtu.be/GuzKSUMyCUM
‘These people’ are generally replying to the suggestion that if people don’t like iOS because it it doesn’t allow sideloading, then why not buy Android?
From what you and others are saying, sideloading may not even be an appropriate term - you make it sound like you can just install software from the web on Android directly.
So you take an uncomfirmed report over video proof. Got it. No wonder your "facts" are all wrong.
> you make it sound like you can just install software from the web on Android directly.
Yes, that is the case. Sideloading is just the ability to install apps from somewhere other than the official store(s) on the device.
If there is a wrong fact that I have stated, you would be able to show an example.
On Android 2.x, I remember apk download installs just failing, until you changed the settings; but everything else has been pretty easy. A Samsung KitKat phone I was using recently was even nice enough to have a 'allow just this app, or let it be wide open' checkbox.
About the only thing I sideload that's not on the play store is rooting toolkits, but sometimes it's convenient to get the APK another way (Google Play requires logging in to Google, which is hard to undo, for example)
I have frequently read that sideloading is impractical as a way to sidestep the store on Android when delivering software to consumers, but that sounds like it’s just wrong.
I wonder which version this changed in.
Some users will be scared away by the warning text, and it's hard to prepare them with example dialogs, because there's such variation.
You'll need to build your own auto-update service, which (probably?) can't do delta updates like Play can. If you have a lot of users, and you can't dither the downloads[1], you may have a huge download peak.
If you have native libraries, off store downloads need to contain all the versions, but on store only downloads the arch appropriate ones.
If you make apks for download, people will archive them and make them available to others, even after they're obsolete. This happens with play store too, of course.
People who download your apk directly are also likely not to have play libraries or access to google etc. If your app depends on those things anyway, you're going to be missing functionality, or have to implement fallbacks for say, maps and push, etc.
People are still going to look for your app in the play store, so you probably want it there too; at least if it's not something that Google will disallow.
[1] Android really likes grouping background timers, so you will probably experience peaks at local X:00 for all of your users. And local X:00:08 for your users on networks with slightly off clocks
Sideloading doesn’t refer to installing apps you have developed yourself.
It’s about distributing software outside of app stores.
If you can do one, you can trivially do the other. It's effectively the same feature to the end user. I develop my own apps and upload them to cloud storage to install them on all my devices.
You can install your own app on your own iOS device without using the store, but you cannot distribute to end users.
That’s why we say Android supports side loading but iOS does not.
The two things are not one and the same.
My own devices and the devices of my friends and family are end users. I do not have to connect the devices to my computer. On iOS, you cannot do this without paying Apple yearly unless you want to deal with reinstalling every week.
> The two things are not one and the same.
They are enabled by the same mechanism. If you have one, you automatically have the other.
You said: “Hundreds. I develop apps for my own devices. This is supposed to be a forum for technologists.”
I said: Sideloading doesn’t refer to installing apps you have developed yourself.
You said: If you can do one, you can trivially do the other.
This is clearly not true. You can install apps you have developed yourself on your own iOS devices for free, but you cannot distribute them. They do expire, but you can certainly install and use them on your own devices.
So then you changed the goalposts to “My own devices and the devices of my friends and family are end users”.
Which is not what you originally said. You originally said “for my own devices”.
We agree that sideloading is about distributing software to end users. Not just your own devices.
The two are not one and the same mechanism. The fact that you had to change your qualifier shows this.
https://www.phoronix.com/scan.php?page=article&item=macos101...
Their phones were slower at productivity tasks than midtier phones from the previous generation for many years.
https://www.youtube.com/watch?v=emPiTZHdP88
https://youtu.be/hPhkPXVxISY
https://youtu.be/B5ZT9z9Bt4M
I agree that Samsung's phones are also overpriced.
That seems like a straight up falsehood.
iOS is even worse, taking vastly superior hardware and still managing to perform worse on standard productivity tasks.
As to your claim about iOS. There is literally nothing to substantiate it.
You are simply lying and hoping nobody checks.
From the link I posted: "Ubuntu 19.10 meanwhile had a 29.5% advantage over Apple macOS..."
Ubuntu 20.04 is faster still on that set of benchmarks, and ClearLinux has a 10% performance increase on top of that.
>It shows performance on an extremely narrow test.
No, it includes a very broad range of tests. I just highlighted one of them, on which MacOS performs particularly poorly and which affects software a lot of us use.
> As to your claims about iOS. There is literally nothing to substantiate it.
I gave you three links to substantiate it. It also matches my own experience.
These technologies are long deprecated on Apple platforms.
It’s completely unrepresentative. But sure, if you rely primarily on Java or OpenGL for your workloads, I agree that a Mac isn’t the right choice for you.
It’s a lie to say “The software adds a 30% performance penalty on top” based on these results. It doesn’t.
If you have something credible to link to about iOS performance being slower, I’m interested, but I’m not going waste time watching YouTube videos that nobody else is going to bother with.
If it’s that bad, you’ll be able to find some credible analysis in writing. I’m guessing you can’t.
This doesn't matter to the user, who is still using apps like IntelliJ IDEs. To the end user, this is a problem with MacOS, which does not allow GPU vendors to update their OpenGL drivers. Meanwhile, Ubuntu has far superior OpenGL performance and superior Vulkan performance on the same hardware.
> It’s a lie to say “The software adds a 30% performance penalty on top” based on these results.
You keep saying that, but you haven't explained why. MacOS is also twice as slow on git operations according to the benchmarks. Java2D and git are software that people use that are multiple times slower (not merely 30%) on the same hardware.
> I’m not going to watch YouTube videos.
Then I'll post text summarizing them. Android on midtier previous generation phones launches apps to interactivity faster than iOS running on latest generation hardware, and this has been the case for about ten years now. There are hundreds of videos on YouTube substantiating that.
Edit to respond to below comment due to rate limiting:
> YouTube videos, however many, are not a credible source of operating system performance claims. You can find YouTube videos supporting flat earth theories or that Obama is a lizard alien.
The YouTube videos doen't say that Android is faster. They show that Android is faster. You seem to not understand the difference between people claiming things are true and people showing things are true.
It's the same with the 30%. I showed a suite of benchmarks where MacOS is 30% slower on average. It was many times slower on a few specific benchmarks I called out.
> If you are a heavy Java or OpenGL user, don’t by a Mac.
I'm glad we can agree on that. You forgot heavy git users.
Edit 2:
> It creates a dishonest impression of the thread.
How does replying with edits create a dishonest impression of the thread when I very clearly indicate which comment I am replying to? If you would like to respond normally, there is a very easy way to enable that. Simply upvote my comments to disable the rate limiting.
If you are running a git server farm, don’t use macs. If you are a developer using Git, you’ll be just fine.
These just aren’t representative of most people’s experience.
It’s a lie to say the software is 30% slower.
It’s even a lie to say it’s 30% slower for an IntelliJ user.
It’s only 30% slower on a narrow benchmark.
YouTube videos, however many, are not a credible source of operating system performance claims. You can find YouTube videos supporting flat earth theories or that Obama is a lizard alien.
If you can’t find any article anywhere substantiating your claim, I think we can conclude that it’s not supported by evidence.
If it was that bad, a reputable site like ars, or anandtech would have shown it.
It creates a dishonest impression of the thread.
I gave you a source. The sluggishness is something I notice when I use MacOS.
> If it was that bad, a reputable site like ars, or anandtech would have shown it.
It is that bad. Hundreds of YouTubers have shown it, and you can do it yourself to confirm. I have friends who have iPhones. The launch times are noticeably slower.
I'll even give you my speculation for why this is the case in order of impact:
1. Android's zygote based process initialization.
2. Developers optimizing for the $50 Android phones in the long tail.
3. GC instead of ARC.
The software is not 30% slower.
There are a set of cold boot launch times which can be shown to be slower in a video, but this is not a metric of software performance nor does it impact users.
You’ve attempted to use a set of YouTube videos to justify a false statement.
As I have said before - if iOS was slower than Android you’d be able to find a reputable source to show it through analysis, not some staged YouTube videos looking for clicks.
I showed you that it is, and you keep saying that it isn't. I even gave you some examples that are more than 100% slower.
> There are a set of cold boot launch times which can be shown to be slower in a video
That's what I said they were. You kept not believing me even though I showed proof. Now you say that it doesn't matter. It is in fact the biggest thing that matters for productivity apps, aside from UX, where Android wins by a bigger margin due to smart replies and other actions in notifications.
> You’ve attempted to use a set of YouTube videos to justify a false statement.
You keep saying that, but you've just agreed in this comment that my statement was wholly correct.
Get your fingers out of your ears.
This is a false statement. The YouTube videos do not change that.
Moving the goalposts to “the most important thing for productivity apps”, doesn’t change the original statement.
Taking aside the moved goalposts, even your new statement is false. Cold boot time for productivity apps is not the most important thing for productivity apps, since cold starting a regularly used app is rare.
The fact that you know these videos only show a rarely occurring situation, shows that you know you were lying when you made the original statement: “Worse, the software adds a 30% performance penalty on top”.
Also I said: “There are a set of cold boot launch times which can be shown to be slower in a video”
To which you said: “That's what I said they were.”
If this is true, you’ll be able to link to the comment where you said you were talking about cold boot launch times that precedes mine.
The pattern here is that you make a general statement which is completely false as written, and then attempt to change the goalposts and justify a much narrower statement that doesn’t actually support what you originally said.
I never said they did. Can you not read? How many straw men do I have to burn down to have a discussion with you? The substantiation comes from an article with benchmark results.
> Moving the goalposts to “the most important thing for productivity apps”, doesn’t change the original statement.
I made two separate claims: one that MacOS is slow and one that iOS is slow. There are two separate goal posts that I put up, and neither one has moved. It's like I'm arguing with a post.
> If this is true, you’ll be able to link to the comment where you said you were talking about cold boot launch times that precedes mine.
I said it is faster at launching apps to interactivity. This is for cold boot and not. The apps launched after the first in each video are long after cold boot.
Your reading ability is so low that it is useless to carry on a discussion with you. No wonder you use Apple products. You're the rube who actually believes Apple's marketing.
No. That’s a new statement you are making now.
You made this claim:
“The software adds a 30% performance penalty on top.”
Which is false, regardless of which platform you are talking about, and not supported by the links you shared, which in both cases were corner cases that cannot support a general claim like this.
As I have said before, if this claim were true, you’d be able to find a reputable source, e.g. Ars or Anandtech.
On the other hand, Androids have a reputation to get somehow jankier or sluggish over time, and that surely must affect its brand and overall standing for consumers.
I imagine you watch lots of Apple ads.
https://www.npr.org/2020/11/18/936268845/apple-agrees-to-pay...
I understand there are arguments about why this is a good idea, but Apple is settling, which tells me a fair amount about how Apple thinks those arguments would land in court.
Back in the Intel days you were paying twice as much for a Macbook laptop that used the same CPU as whatever Windows laptop with similar specs.
Oh and there was also a couple of generations where Apple had pretty much kind-of exclusivity on Intel's newest CPUs and they were really only available in MacBooks for the first few months.
Take a watch at any of the Louis Rossman's "Think Different" Series to see Apple Build Quality....
Seems like you got sucked up into it.
Edit- butterfly keyboard, airpods, bad iphone signals come to mind
You know what, if you look close enough, "they all suck".
Nice Ad hom though. :)
Apple is a fabless designer, other vendors have access to TSMC as well, as long as they have space capacity. Realistically, other ARM vendors are about 2 years behind. A Snapdragon 875 scores the same as an Apple A12 on Single Thread Geekbench.
On GPU and TPU, Apple isn't that far ahead at all. TPUs are relatively simple devices, and the Snapdragon 888 already has almost double the A14 performance in TOPS on paper. GPU wise, the A14 (PowerVR derived) GPU is roughly equivalent to a 2016 era NVidia 1060. AMD's RDNA2 based cores for SOCs are likely more powerful and more capable (e.g. raytracing acceleration)
Much is made of how far Qualcomm is behind Apple, but like with AMD and Intel, Qualcomm has a wider market focus to address. Apple sells only a few SKUs, Qualcomm needs to make chips for a much wider array of demands, and so they're a jack of all trades, master of none. In much the same way, AMD and Intel have desktops and enterprise vendors to satisfy, including people running SMP systems. Does the M1 support multiple M1 SMP? Does it support ECC? The other vendors are kind of hamstrung by trying to make one architecture that pleases too many markets at once.
Look at the Anandtech Snapdragon 888 article: https://www.anandtech.com/show/16271/qualcomm-snapdragon-888...
"Qualcomm’s 25% generational boost is also less than Arm’s advertised 30% as the new S888 continues to use a 4MB L3 cache for the CPU cluster, versus Arm’s envisioned 8MB configuration for a high-end 5nm SoC with the new X1 cores. Qualcomm explained to us that this was simply a balance between cost, implementation effort, and diminishing returns of a higher cache configuration design."
Basically, Qualcomm needs to worry about what their customers are willing to pay for the chip and how much work it takes to integrate. Apple doesn't, if need be, they can bump the price for a more expensive SOC, Qualcomm Android vendors can't.
25% CPU performance uplift and 30% GPU performance uplift for the 888. the A14 gets 1583 Single Thread in Geekbench, the 888 will likely turn in a final Single Core perf between 1300-1450, only 9% less than the A14. The situation is the same for multi-core, roughly on par, and on Antutu, the Snapdragon 875 beats the A14 substantially, and wins on several 3dMark tests.
Apple does not have an insurmountable lead over the other vendors in terms of SOC, I'd argue that their primary advantage right now is their software has always been better. In particular, WebKit's JIT for ARM does a lot better than V8 for ARM, and Android Dalvik does not produce code that runs as well as LLVM on Swift (plus there's generational GC vs ARC+refcounting).
Otherwise, a 9% CPU advantage in single thread performance is nothing to write home about.
I’d say Apple’s customers are far more sensitive to performance than Google’s given what Android users have been willing to put up with (e.g. flagship SoCs that are years behind what’s in last year’s iPhones). If you factor in broader aspects of performance (e.g. Face ID, fingerprint unlock speed) it’s clear that the _only_ thing most Android users care about is cost. I’m not saying this to diss them, I just think the Android manufacturers owe it to their users to actually produce competitive hardware and software.
P.S. if you factor in longevity, Apple products are usually cheaper, too.
Maybe they meant both independently. As an example:
- A friend of mine just upgraded out of his iPhone 6. Until recently performance and storage seemingly just weren't that important to them.
- Another friend of mine will just buy iPhones, no matter the cost.
Both of these friends stick with Apple because they like and care about other things about the ecosystem more so than performance or cost (independently), whereas OP was perhaps implying that Android users tend to care more about "performance to cost ratio" since they could as well just buy a different phone from another maker and get the same Android experience. This of course, in the context sticking with one phone maker or another.
In the US iPhones are entrenched because of network effects (iMessage or whatever it's called) plus the Apple ecosystem. In the rest of the world where this is less the case, iPhones are a status symbol. Not even expensive Android phones have the halo iPhones have, especially in poorer countries.
Yes, people will enjoy the extra performance or extended software support, but that's not why they will buy them. I doubt 99% of regular users even know about those aspects.
Their high pricing has to do with the slew of software and hardware features they include, many of which are executed at least reasonably well and later trickle down to mid-tier brands like Google's Pixel line or more conservative high-end brands like Apple. For instance: DeX, more flexible fast USB C and wireless charging than most manufacturers, pen/remote support with in-device charging and corresponding apps, Samsung Pay with magnetic stripe emulation, etc.
Samsung isn't focused on raw computing power, because they largely depend on the same chips as most of their manufacturers, but if you've used a newer Galaxy S/Note device the level of hardware polish and random "gimmicky" but occasionally useful features far outpaces a Pixel or similar.
Disclaimer: I currently own a Pixel (because there are other things that Google competes on) but last owned a Note 9.
Samsung doesn't even ship their own phones to the US with Samsung silicon. Is this a patent issue with the modems?
Second, my understanding is they don't have CDMA support, which is still relevant in the US. So they either use Snapdragons, or pay Qualcomm for the patents and then go make a new SoC. I guess it's easier to just pay Qualcomm for the Snapdragons.
Not for long. Verizon is shutting down their CDMA network at the end of the month.
But yeah, Exynos is garbage.
I also still can't believe the iPhone launched without 3G support!
The original iPhone also shipped without CDMA support. (no 1X, was GSM-only)
2. Qualcomm patents on CDMA and having much better modem.
3. Qualcomm's GPU being better than ARM Mali and CPU being better than Stock ARM ( Samsung ) implementation.
But All of these are changing and Samsung wants to succeed in these areas. Foundry is catching up a little bit, so may be a little more than 1 year behind in TSMC in terms of league edge and capacity. ( Forget about their goals and Roadmap as well as investors notes they are even worst than Intel ). They have signed a partnership agreement with AMD bringing RDNA to Mobile. Their Modem is improving with each generation, and the patents issues has been sorted out recently. ( Which is pretty much the same deal as Apple )
It will take some time. 2021 Exynos may be a little too early so 2022 seems like a safe bet. Although Qualcomm isn't sitting still either.