Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That’s good news for people who enjoy the freedom of using the device they own in the way they want.

Having (alt store) presence in Australia, Brazil, EU and Japan is in fact more than enough for many indies - one can even begin to imagine ignoring the US as a region.

 help



It’s also great news for app developers.

First, Apple does not follow the same rules they set for developers.

Second, Apple does not treat all developers equally. We have functionality we’re unable to offer to iOS users.

The same feature, including technical implementation mechanism, is available in Claude and Gemini. It’s unfair.


whats the feature?

hwaccel for vp9 decoding is unavailable to proles who's fault is not being google

Why? How in the world is hwaccel gated behind an entitlement??


as of iOS 26.2, you are allowed to play VP9 videos without the entitlement.

https://github.com/PoomSmart/YTUHD/issues/72#issuecomment-46...


I’ve been thinking about open source replacements of proprietary companion apps. It’s easy enough to reverse engineer Bluetooth protocols now, but you can’t run these in websites. Putting stuff on the App Store is too expensive but sideloading could be viable.

Side*note: I really hope we can move away from the term "sideloading" which makes it sound like we're doing something on the down low.

Installing something is a perfectly normal operation - it's the App Store that's the special case :).


Direct Install, or better yet, Owner Controlled Install.

Lets call it what it is.


Ages ago there was this term "Device Neutrality", first introduced in 2011 at the European Parliament and later incorporated in the Digital Markets Act

https://en.wikipedia.org/wiki/Device_neutrality

I guess Apple prefered the pejorative "sideloading"


Yes, how about just "loading"?

You actually can use most bluetooth apis in websites on most browsers outside of iOS [0]. I used recently this tool [1] to program my baofeng radio and the bluetooth aspect of it worked great, but I did end up having to reverse engineer aspects of the payload to get it encode and decode all the channel configuration correctly.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

[1] https://dz0ny.github.io/5r-mini-ble-tool/


> one can even begin to imagine ignoring the US as a region

As someone from that region, this is probably a good idea for all parties, right now. I'm not fond of our current trajectory, and the outside pressure to change isn't sounding unreasonable.


You think an indie dev in Brazil ignoring the US as a region will change anything?

sandpaper is useful because of the aggregate

But that is the region where most developers would want to target to get more revenue

This is actually outdated information. The inflection has already happened and the split is 40% Asia and 40% North America with NA losing ground over the last years and Asia gaining that ground.

Combine with that other markets also getting bigger like South America.

The reality is that NA had their smartphone / mobile boom already and the rest of the world is still catching up. There are more smartphones, apps, features, services, etc. to be gained by selling to the massive influx of new customers versus trying to cater to the old audience of North America.


My experience is that while other regions have a lot of users, my revenue is still 90% from the US for a location-agnostic product.

In the vast majority of cases, Asia and SA won't touch your product if you don't have deep familiarity with their markets, their idiosyncrasies and have a competitive business model there. Getting folks in these markets to pay isn't easy, friend.

And that's why we keep having these conversations in English on a US site about products made by US companies.


It's terrible news for anyone who has some responsibility for the security of environments in which these devices are used.

Right now we have a relatively high confidence that as long as the devices are not jailbroken and are kept up to date they are relatively secure.

What this change means for people like me is that either there is some capability to detect whether third-party app stores are in use on a device and we will set a policy that disallows anyone using such things from accessing company data/services, or we have to lock out the devices altogether.


The entire world doesn't want their devices that they bought and own to be beholden to the corporate whims of Apple or Google just so your job can be easier.

Surely it's possible to treat phones the same way as computers in corporate settings? Normal users aren't usually allowed to install whatever they want on their work PC, so why their work phone?

I think they were talking about bring your own device.

How many people bring their own laptop to work? (ignoring self-employed people and the like which this line of thinking really doesn't apply to) Phones should be treated the same way.

Personal devices shouldn't be used for work purposes to begin with. If work has security requirements regarding what phone and what condition it is in, they better be supplying their own phone to ensure those requirements are satisfied.


> But they benefit from accessing their work email, Teams chat, calendar, etc. from their phones.

No, they don't benefit (cause it means they check work mail on weekends or evenings), but their employer do...


Vast majority of the people don't have the need for a separate work phone. But they benefit from accessing their work email, Teams chat, calendar, etc. from their phones.

If work wants to be picky about what devices can access those things, but still want their employees to do so, they should provide devices for that. If they don't, well, then the employees get to not do work during non-work hours.

The ruling doesn't ask Apple to get rid of app sandboxing. The ruling explicitly notes this:

> Moreover, because iOS apps are sandboxed, as implemented in other jurisdictions, apps available through alternative distribution will be sandboxed, which further strengthens security and reduces the likelihood that any app will compromise other apps [...]


Or your company buys phones for its employees and allows only those work phones on its networks. I understand that this is an extra cost and phones are maybe more expensive than some laptops good enough for working with Office.

"Billions of consumer phones must be locked down because our IT department is completely incompetent and incapable of providing locked down work devices"

Some people have a life outside of work and don't really need "the security of environments"

Uhm, disallowing third-party stores, sure, but you draw a line that allows a non-jailbroken and updated device to be able to access company data? How is the lack of third-party app stores gonna prevent someone from sending sensitive data through the Mail app or to iCloud? Shouldn't company devices be managed with MDM to begin with?

> It's terrible news for anyone who has some responsibility for the security of environments in which these devices are used.

On the contrary, it allows app and payment security to be better than what Apple offers.


It also allows it to be much worse too. I can't wait to do tech support for my grandparents that followed the instructions to install ScamAppStore to install an app they saw on a Facebook ad.

I do tech support for my parents that both use Android. Haven't had a sideloading incident once in the decade+ they've used it (although I did show my dad NewPipe, which he uses constantly now).



Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: