VLC vs. the App Stores
mjtsai.com
mjtsai.com
The remark here is that AppStores have so much power that they are forcing limiting rules, and few people complain, because they have no choices.
On Android, we can either give Google our private (!) key or not support existing Android versions, and there is (as usual for Google) no one to discuss this with.
On Windows, they changed soo many times the backend of their store, that even with support from the top of the hierarchy, we cannot even update our desktop apps (change a URL, not even a binary…)
Apple, so far, is less annoying, but to support old versions (iOS9 or 10) is an always on battle.
Apple AppStores does not allow GPL, Microsoft does not allow GPLv3 and Unity does not even allow LGPL…
It’s very frustrating and time consuming, but because we don’t make money out of those, and we are on more platforms than anyone, we can complain publically…
BTW, I use VLC-Android-3.5.4-arm64-v8a.apk to listen to internet radios I’ve subscribed. Very few players support M3U files with streaming URLs inside which include API key to authenticate. VLC does.
I think current antitrust legislation isn’t enough. We need different laws with easier enforcement. And instead of wasting time with laws and legal battles, we just need trillion dollar companies to be heavily taxed and use that money to fund competition.
> E.G. for files/folders...
* Official not hobbled FS application, 'opens' files
* Same Directory (read only) allowed access
* Same Directory (write also) allowed access
* Path & subpath RO
* Path & subpath RW
* Full ('SD card' only?) RO
* Full ('SD card' only?) RW
It'd be nice if some of the other issues could be elaborated upon. Like that weird Android TV API version issue.
The current Android permission model doesn't allow, for example, to browse the data of the applications, i mean their folder in /data. For example if I want to backup app data on a cloud service, or make a full backup of the device, I simply can't. Either the app has to support a backup and restore feature to external storage, or you can't. Or I want to make some kind of integration that requires reading/writing directly on the sqlite database of an app, because it doesn't provide the facility that I need.
To me it doesn't make a lot of sense, and it's the only reason I root my devices.
Fun fact: whenever you download an image from the official Twitter android app, it saves a copy of that image to the app's data (not cache) and just leaves it there, forever. Since I have root, it doesn't really matter since I can literally just load up a file manager and delete the files as I would on a PC. But without root, there's nothing you can do about it other than wipe the app data completely every once in a while. Thankfully you don't lose much when doing this for this app, but this is far from the only app that has this sort of issue.
*A few apps like Signal think they know better and opt out of iTunes backups
I do tend to agree that that kind of forward secrecy isn't actually important for very many people, and most of those people have other, bigger leaks to worry about. I don't use Signal myself. But it's still the big thing Signal was originally created to offer.
The answer to this one is obvious. Drop support for API <30. The older version of the app will work well enough for those users.
At present nobody is getting updates. Giving updates to everyone >=31 is an improvement to the status quo.
Don’t bother with the Windows Store or Mac App Store. Those users don’t need app stores.
I think it’s not up to the individual developers to make these platforms a good place for their users. The platform owners already control that fate. If your Android TV device becomes a brick with apps that can’t be updated after ~5 years that should teach the customer to find something else next time.
Well for who already has the app installed, but if one is on API <30 and wants to install VLC from the Play Store, it can't.
> At present nobody is getting updates. Giving updates to everyone >=31 is an improvement to the status quo.
Would a user who does not already have VLC installed be able to download it in this scenario?
Windows on ARM can install software outside of the Windows Store, and VLC offers an EXE binary for it.
Android Studio [Iguana | 2023.2.1 Patch 2 | Built April 4 2024] states that for minSDK API 30, an app will run on 59.8% of devices.
I assume it's because they won't make any money for the platform.
I haven't had a problem and I don't even work in tech but I personally know at least 3 people who work at google off the top of my head... this VLC guy should know way more
That said, it's no excuse for Google's now, legendary, lack of customer service...
or... just post on HN or know a reporter from NYT to write something up...
[1]: https://f-droid.org/en/docs/FAQ_-_App_Developers/#will-my-ap... [2]: https://code.videolan.org/Skantes/vlc-android/-/blob/master/...
What’s still concerning to me in the US is how the courts seem “just ok” with no reasonable ability to sideload on iPhones, giving Apple more or less unilateral authority to squash competition if they want.
I know it’s technically possible to sideload on iOS if you have a Mac and directly compile the App yourself in Xcode, but Macs are pretty expensive, and that requires understanding dev tools and the like.
Last time I did this I was using Cydia Impactor but it’s been a while. I had an automatic local resigning tool on my device that required jailbreak but I think you can also do this with AltStore/AltServer iirc without jailbreak or just do it manually with Xcode.
To your original point upthread, you can run Xcode on a macOS virtual machine if you don’t have a real Apple desktop or laptop.
I haven’t ever had success with getting macOS running in a virtual machine but I admittedly haven’t tried in awhile and didn’t spend a ton of time on it.
https://developer.android.com/distribute/marketing-tools/alt...
There has been nothing more sad (or less unexpected) than Apple's tragic fall from grace. Maybe they were rotten from the start, but it feels like this squandered golden age of mobile computing is what they'll be remembered for. 15 long years of spooling up the money printers and praying nobody gets loud enough for the regulators to hear. What a sad waste of all our lives.
No complete account of Jobs can escape his horrible interpersonal reputation. Much as the modern account protests, his history was vitriol and struggle up to the very end. Heroize him at your own risk.
Sideloading in the context of installing apps on mobile operating systems has a distinct meaning.
https://en.wikipedia.org/wiki/Sideloading
> When referring to Android apps, "sideloading" typically means installing an application package in APK format onto an Android device. Such packages are usually downloaded from websites other than the official app store Google Play. For Android users sideloading of apps is only possible if the user has allowed "Unknown Sources" in their Security Settings.
> When referring to iOS apps, "sideloading" means installing an app in IPA format onto an Apple device, usually through the use of a computer program such as Cydia Impactor or Xcode. On modern versions of iOS, the sources of the apps must be trusted by both Apple and the user in "profiles and device management" in settings, except when using jailbreak methods of sideloading apps. Sideloading is only allowed by Apple for internal testing and development of apps using the official SDKs.
Did they expect that Apple would stop dropping support for old hardware for them?
What is their thread model exactly? Are they aware that Android and the PlayStore is made by Google?
Besides, giving Google the keys to sign the APKs allows Google to make tailored APKs for devices with exactly the right ressources, saving bandwidth and disk space for users. I just had a look and right now I see that VLC is shipping hundreds of KB of pngs that are going to be unused, because they are shipping pngs for all the DPIs.
The way Google uses those keys forces them to be on, or at least usable from, many machines accessible to many people. That is bad key hygiene, and exposes the keys to many threats of many kinds.
The people who maintain Android are not the people who curate the Play Store, nor are they necessarily using exactly the same tools or infrastructure. Letting the Play Store subvert security unilaterally enlarges the human, organizational, and technical attack surface for any number of threat actors. Furthermore it's easier to unobtrusively modify one user's copy of VLC than to modify one user's copy of Android, and also easier to change it back to cover your tracks.
All of this significantly increases the chance of the whole system being subverted by any of a variety of threat actors from random rogue employees right on up to nation states.
> Besides, giving Google the keys to sign the APKs allows Google to make tailored APKs for devices
That could have been done without giving (any part of) Google the keys, using an obscure technique known as "a system design and manifest format that aren't minimum-effort-by-minimum-talent garbage".
This is all really, really basic stuff. You don't just go around giving away giant attack surfaces for free. And Google is getting it wrong because doing it right would be slightly inconvenient.
Then the teams should clearly distance themselves from each other. As long as this is not done, the teams have to accept that they are considered to be just "different tentacles of the same evil kraken" by the public.
I do not care about who the public perceives as evil. I care about the number of people who can put me at risk.
Android requires signature with the same signing key, when updating the application.
The extension API is terrible. One of my pet peeves are the subtitles. You cannot take screenshots without subtitles when it's on, because it's rendered on the same overlay as the video.
Please put the subtitles on an overlay... If the audio volume can be on an overlay, so can the subtitles be. VLC needs to ramp up development and UI efforts, because PotPlayer is a much better, feature laden player, although it's Windows only :(.