Wasn't your intention whatever you typed in? That doesn't make you an artist and I don't want to hear the music AI made that you happened to type some words to and hit enter.
Tons of professionals use logic. Really, you will find money making musicians using any of the major daws. Pro tools might still be the standard for recording studios but that's likely it.
My point was more that creators will often use more than one tool.
I know Logic is widespread amongst beat producers and songwriters, especially in the US. But you will also often see tracks getting produced on Logic but the final mix then happens on Pro Tools (by professional mixing engineers).
But that's why I explicitly mentioned Logic, I think it's the one pro app from Apple that still deserves the moniker, at least in regards to where it is used. The video stuff not so much anymore.
Logic Pro gets regular updates. I believe most of it is AI driven nonsense but they are making changes. Flashback capture was a nice fairly recent addition and surprising this wasn't implemented sooner. There are also regular bug fixes and performance improvements. I can't speak for the other apps.
It helps that you have to continue to buy their hardware to keep running said software. I guess they could be greedy and keep making me pay for Logic every few years so I'm happy they don't do that but they're still making money off my initial purchase of logic just in a different way.
I am not sure if you're disagreeing with the original poster here but you're both saying the same thing in different units. 1g/kg != 1g/lb which is A LOT more protein and a complete waste of time. As a mostly vegetarian who lifts regularly, I am targeting a bit more than 1g/kg but being from the US it is a lot less than 1g/lb. :p
A lot of it comes down to what the person you're responding to said, seasonality. I grew up in a very rural farming area and now live in a very large city. While the produce at the grocery store is generally inferior to that of being near a farm, when things are in season, it is at least comparable. That apple you buy in July is never going to be as good as one bought in the fall, it doesn't matter where you buy it from.
You can though because a lot of those things you're talking about are available for any app. Sure Apple does have some private frameworks and what not that aren't available to everyone but I imagine if you wanted to recreate what the photo app is doing you'd be able to in 4.2mb or less.
The iCloud Photo Library doesn’t have any public APIs that I know of. You simply can’t recreate the Photos app completely, regardless of app sizes. Apple values deep integration into the system more than it values giving third party developers a fair chance at cloning their app.
I'd bet my money that you can roll your own iCloud-esque Photo Library and it still won't be near the 100MB territory if you just use native libraries for the UI. Everything you'd have to do from scratch: cloud auth, encryption, syncing, compression, transcoding, etc. is all at most a few MBs combined, not to mention that all of these except cloud auth are already in the built-in libraries on iOS that any app can freely use.
What the apps here are doing is shipping whole (UI) frameworks and tons of old code and assets that aren't really used anymore but nobody dares to remove.
You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it. If you don't like that example Chrome and Edge are both forced to use WebKit on iOS but are still much larger so.
If the point of a Google Photos app is to access / back up your photos via Google Photos (web), then it seems rather dubious that making API calls to a cloud server is an endeavour that takes hundreds of megabytes of code and resources.
If, rather more accurately, the point of a Google Photos app is to provide a photo editor and various other photo-adjacent functionality coincidentally including the ability to back up photos to Google's servers, then again that raises the question of why Apple's equivalent app is so much smaller. Are there image-related system frameworks that Google cannot use that Apple is using? Then sure, feel free to count them in Apple Photos' "true" size. But if Google simply won't use them then IMO it's fair to ask if the size of what they're shipping is worth it.
Part of it is resolution. The icons and such in apps are much larger now than they were in 2013. Besides that I mentioned this in another thread but rarely will a team clean up after itself. There's probably tons of dead code and what not in a lot of these larger apps. I know all the ones I've worked in had a lot of bloat just from years of work. Some feature gets added 5 years ago by a team that no longer exists, it was turned off and no longer used but who is going to remove it?
Besides that, there's just a lot of garbage that gets added by various people with different interests. An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.
> An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.
Frameworks from other companies. A lot of it is analytics/tracking, some payment processing, etc. There are a few open source libraries we're using as well but those probably are <5mb if I had to guess although I never checked.
Again, a lot of these companies have also been around so if my app has a ton of bloat from years of work, we're bringing in frameworks from other companies who have been around for years as well and probably have a similar amount of crap in their code. Plus they probably want to track everything we're doing so they're bringing in their own third party libraries. It's kind of ridiculous but that's where we're at.
Bigger companies won't have as many third party libraries as they can afford to do it in house but they're still bringing in similar sized libraries to do the same things.
Imagine, it's not just making sure your code is secure, but your also counting on all those libraries's being secure. Let alone all these frameworks as you say - payment, advertising, analytics... You could have the most secure code ever, but when it is just one link in a chain outside your control, best not overthink it or you won't sleep.
You can see why bug bounties get rewarded well. Though mindful, money is not what drives everyone. Then there are the greedy, in which such exploits value on the black market can be higher. Not forgetting government agencies level.
I wonder which email client will break the 1GB mark, and when we will see a resurgence in reducing bloat. I'm sure that phase will come, did for Microsoft once.
Woof. This is just so wild if one ever stops to think about it. ~300mb of tracking for a single app is bigger than the entire hard drive of a fully internet-capable desktop computer in the mid '90s.
Huh, is there a requirement that they be rasterized at build time? If I had a choice, I'd rather ship the SVGs in the bundle alongside a renderer like ThorVG and render at runtime. The renders could even be cached if the rendering itself was expensive.
If you’re including these assets as UI elements, they would be rasterized anyway and copied to a GPU bound buffer for the frame blit. Doing so at compile time increases runtime performance.
You can of course override this behavior and redraw your vector every 8.3 ms if you want, but I promise you that this is not faster. For sparse pyramid-tiled vector images like Google/Apple maps, this is a two step process using the latter method followed by the former.
Historically, raster graphics won out because they used less resources. Perhaps that's changed. If so, it would make sense for various OS's to start working on native support. Irix did it in the 90's. It can be done now.
Yeah but I would argue that they just used cheaper ressources since historically has been cheaper than compute.
It's not clear if compute can be cheaper than storage still today.
On one hand you can afford to use less storage but you have to use GPU power everytime to draw graphics, if the chip can support the compute requirement you can save on storage, but you pay with higher power draw at every interraction.
On the other hand you can just put more storage, chip assest that are rendered for the device they'll be used on and be ok.
Outside of crisis like now, storage should be cheaper in the long term I think. I doubt there is that much benefit in having assets being able to resize to any arbitrary resolution. The definition used in phones isn't that far away than what is used in laptops, monitors and now even TVs.
Something to think about is that icons/assets often need to change shape slightly as they become smaller or bigger for optical reasons. So even if you manage a fully vector scaled UI, you might still need to have difference depending on DPI to reading distance ratio. Rasterized assests might still be the real answer for a very long time.
Considering how bad is the iOS 26 release on performance, because of its dynamically computed interface, I'm not sure it's worth pursuing vector UIs, it doesn't make a lot of sense to make a more powerfull chip just to draw prettier or more "pure" interfaces...
we've been able to "preserve vector data" with pdf and svg image resources on ios for a long while now... compile-time rasterization is the default though...
It is dependencies but not from the GUI. As someone who has worked on several very large apps I can tell you 99% of the bloat is garbage. Someone somewhere wants this SDK from their friend's company in the app. Some manager wants to track X using this very specific framework. Some designer decided to add in animations in one screen that requires another framework to run and also 10mb in assets. etc, etc, etc. If your app is 10+ years old this all adds up and no one ever cleans any of it up. There's probably like 100mb of crap you can delete that doesn't even work anymore but who has time to remove that?
reply