3 ms·

And yet with the Raspberry Pi being so popular and being on the market for so long, there are still a lot of packages that don’t support ARM. It’s trivially ea

And yet with the Raspberry Pi being so popular and being on the market for so long, there are still a lot of packages that don’t support ARM. It’s trivially easy to compile your iOS app for 64-bit as well, but like I mentioned... that transition left a lot of dead apps in its wake.

rbanffy 6y ago
Some packages don't support ARM because there is little demand for that. People won't use RPis for heavy number crunching or any demanding application. Until recently, you could barely go beyond 2 GB of RAM on any ARM platform and still very few ARM boards will support more RAM than that. Another issue is that most ARM hardware is underpowered and it takes a long time to build and test software on it. Not everyone is willing to do that. Apple is going to change the landscape with a mainstream ARM platform that can compete in specs with Intel desktops and laptops. Let's see what happens then. The dynamics of proprietary software are somewhat different from open source - unless you make a steady revenue from an app you launched some time ago, there is little incentive to dedicate resources to port it to a new platform (even if it's from 32 to 64 bits) unless you expect it to drive new sales. There is no penalty apart from lost potential revenue and a huge incentive to focus on the next product.
ogre_codes 6y ago
> It’s trivially easy to compile your iOS app for 64-bit as well, but like I mentioned... that transition left a lot of dead apps in its wake. Most of those "dead" apps were not under active development and had no income flow. Making a "trivial" change to an inactive project means rebuilding software which you have shelved for some time. If you are actively developing software, adding Intel support to a build is pretty much just clicking the option to build a Universal binary. Adding a flag to an existing build a lot easier than dusting off an old app and making a bunch of tweaks and a new build with near zero chance of return on that time invested.
- freehunter 6y ago
  Again, my concern isn’t over how difficult it is, its that some developers just won’t do it.

rbanffy 6y ago

Some packages don't support ARM because there is little demand for that. People won't use RPis for heavy number crunching or any demanding application. Until recently, you could barely go beyond 2 GB of RAM on any ARM platform and still very few ARM boards will support more RAM than that. Another issue is that most ARM hardware is underpowered and it takes a long time to build and test software on it. Not everyone is willing to do that. Apple is going to change the landscape with a mainstream ARM platform that can compete in specs with Intel desktops and laptops. Let's see what happens then. The dynamics of proprietary software are somewhat different from open source - unless you make a steady revenue from an app you launched some time ago, there is little incentive to dedicate resources to port it to a new platform (even if it's from 32 to 64 bits) unless you expect it to drive new sales. There is no penalty apart from lost potential revenue and a huge incentive to focus on the next product.

ogre_codes 6y ago

> It’s trivially easy to compile your iOS app for 64-bit as well, but like I mentioned... that transition left a lot of dead apps in its wake. Most of those "dead" apps were not under active development and had no income flow. Making a "trivial" change to an inactive project means rebuilding software which you have shelved for some time. If you are actively developing software, adding Intel support to a build is pretty much just clicking the option to build a Universal binary. Adding a flag to an existing build a lot easier than dusting off an old app and making a bunch of tweaks and a new build with near zero chance of return on that time invested.

freehunter 6y ago
Again, my concern isn’t over how difficult it is, its that some developers just won’t do it.