Does anything stops devs from using the Web interface instead of the API? Sure it makes it a bit more challenging because parsing is involved but AFAIK it is completely legal to parse and display HTML output however you want. It's essentially like a browser add-on.
I wonder if Twitter can be killed by the "embrace, extend, extinguish" strategy?
So:
1. Make a client that combines Mastadon/Others and Twitter feeds, making it switching out of Twitter frictionless.
2. Provide extra functionality for non-Twitter posts, encouraging the use of the non-Twitter services.
3. Once have a good traction, penalize Twitter post to further push non-Twitter adoption. Eventually remove Twitter support completely.
1) the law, at least in the US. Laws such as copyright and maybe even the CFAA have been abused to outlaw adversarial interoperability. You'd need to either practice good opsec and operate anonymously or be based out of reach of US-allied law enforcement.
2) Apple (and maybe Google too?) - they will remove any client for a third-party service unless said client has explicit approval from the third-party, all the way up to ridiculous levels such as rejecting an app using the LAN API of smart home devices explicitly designed for this purpose: https://community.lifx.com/t/app-store-rejection-permission-...
Another point to show what Apple's true goal is: To kill general computing. If you buy an iPhone you should be able to run whatever app you want on it. But no, Apple knows best and will not permit you to do anything it doesn't approve of.
As for the APIs being copyrightable see Google vs Oracle.
A phone is no different from a laptop, except that it is smaller and the mouse/keyboard are part of the screen. On my phone, I should be able to:
* Open an IDE and write some code.
* Compile my code (depending on the language).
* Run my code.
The whole concept of "app stores" is absurd. In 10 years, will we be denied sudo rights on our laptops? Will we need to pay a 30% cut to Apple for every program that we install, plus $99/yr if we want the privilege of building code for our own device?
> In 10 years, will we be denied sudo rights on our laptops?
More and more likely. In 10 years' time I'd love to be off the Intel/Apple Mx train and using devices that can run desktop Linux with with RISC-V and Raspberry PI-like SoCs.
In ten years everything will be the same because Andreas Wendker told us that Macs will stay Macs the way we know and love them. He’s neither in marketing nor in sales but an engineer so obviously what he says must be the truth, to put it sarcastically.
«Macs will stay Macs the way you know and love them. They will run the same powerful Pro apps. They will offer the same developer APIs Macs have today. They will let users create multiple volumes on disks with different operating system versions and they will let users boot from external drives. They will support drivers for peripherals and they will be amazing UNIX machines for developers and the scientific community that can run any software they like.»
This is exactly why I bought Librem 5 smartphone, which can do all these things and can even serve as a laptop, if you connect a keyboard and a screen.
Apple ships an app THEMSELVES that enables this (for iPad anyway) https://apps.apple.com/us/app/swift-playgrounds/id908519492 and there are third party apps for general programming as well. I have one for Python (Pythonista) and one for C# and F# (Continuous) on my iPhone right now. There is a HUGE selection of similar apps for general purpose computing on iOS.
These are unique platforms with unique properties in their design. You value them or you don't. Nobody's forcing you to use them for general purpose computing and there are thousands upon thousands of BRAND NEW general purpose computing products with zero restrictions produced every year. People in this thread are being drama queens.
Apple's goal was to kill malware, not general-purpose computing[0] as a whole. Unfortunately it turns out that killing general-purpose computing is an instrumental goal[1] to killing malware: if you want a phone that cannot get a virus then you need someone pre-approving every line of code that hits the processor.
Once you have any entity having control over your device, even if it is for your own benefit and you completely trust that entity, a whole bunch of other competing business considerations come into play. In the case of adversarial interoperability, that means business risks that Apple doesn't want to take on. Let's say that tomorrow Elon Musk goes absolutely insane[2] and decides that third-party Twitter clients are hacking as defined by the CFAA. If Apple knowingly distributes those clients, then they could be held criminally liable for signing and distributing the app.
Less dramatically, adversarial operability implies a lot of support headaches. Apple wants to sell working software, not stuff that needs updates every few hours to keep ahead of updates done on Twitter's side to kill it. Even if they wanted to fight for adversarial interop in court, the underlying constraint of "pre-approve software updates to keep malware away" makes updating the software in real time to work around Twitter's workaround to the software untenable.
For a non-Apple, pre-everything-being-locked-down example of how much of a pain adversarial interoperability is in practice, there's the time Microsoft tried to make MSN speak to AIM. They stopped once AOL started using buffer overflow exploits to validate that you were running AIM[3]. AOL did not need to actually sue Microsoft with a spurious application of the CFAA. They just needed to wrap their API and client in enough garbage to make interop monetarily painful to support.
[0] In the Cory Doctorow sense
[1] AI safety term for "thing you need to do to get to other things you want".
Malware/app security is always the excuse when it comes to app stores, though.
But there's no excuse that their OS can't sandbox apps as best it can to prevent issues like this. Sure there will still be scam apps, but it should be a lot easier to install apps from outside of an app store.
It's just a blatant money grab otherwise; Spotify for example is extremely trusted and unlikely to be malware - why can't they have an "install" button on their site to install their app? Because companies that run the app stores want a cut.
Why aren't mobile OS' more like desktop OS'? Everyone acts like it's about security but then we get things like Pegasus and Google's Project Zero which is constantly finding stuff anyway.
Even now the granularity on permissions and the main problem of user apathy towards this stuff are solvable. I'm on Android and I still don't understand why an app can only ask for gallery permission/access to all files and why I'm not able to only grant it read access to a particular folder in a streamlined way.
All of this stuff should be designed around a user's intentions.
> If you buy an iPhone you should be able to run whatever app you want on it.
I hear this sentiment quite often on HN. Maybe I’m missing something but was this tacked onto the end of those stone tablets that Moses brought down from the mountain?
If not, then it seems like people want this to be a statement of fact when the reality is much closer to:
> If I buy an iPhone I wish I could run whatever app I want on it.
Don't know about Moses, but here's what iJesus had to say:
> The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today..
Regarding point 1, recent judicial decisions on scraping seemed to have entrenched it as legal.
On two, it seems like they are concerned with trademark to me. A workaround could be making a website that parses and displays Twitter content and call it something else. Then, in an app, make no mention of Twitter and only the website.
Apple might not be such a big issue because they allow reader apps. I guess they can ban you to improve their relationship with Twitter but you can also throw a subscription service as an IAP to improve your odds :)
While it's quite possible to build an app that way, using scraping. The danger is that users of that app will get suspended from Twitter (users have explicitly agreed not to scrape), once thats happened to a couple of users, thats the end of your app.
Obviously you can try to obscure that you are scraping, but that is difficult to get right and there is no way back once you get it wrong.
On Apple devices that wouldn’t be an issue because you you can load the Twitter Web interface into a real Safari and get the markup from there for processing. Twitter can try things like CAPTCHA but this will degrade the experience for all Twitter users and you can simply delegate this CAPTCHA to your user to solve anyway.
While for reading that works, there is an easy why via posting to spot people use that app. They can change at any moment the input names so that when posting a tweet you are exposing that you are using the scrapping client.
Yes, but the app is not a human and will likely interact with the website in a more predictable (and thus, detectable) way than the human itself would.
I’ve done this recently. Essentially created a browser extension that combines Mastodon and Twitter on twitter.com. It works surprisingly well, but I’m guessing catching up with Twitter.com changes is bound to be painful.
Doing this requires a fair amount of development time, especially when you can break something else with this and you previously removed all the guardrails.
Fair point. Maybe have a paid subscription with features that benefit social media professionals? There are some popular and profitable services economy built around social media.
I wonder if Twitter can be killed by the "embrace, extend, extinguish" strategy?
So:
1. Make a client that combines Mastadon/Others and Twitter feeds, making it switching out of Twitter frictionless.
2. Provide extra functionality for non-Twitter posts, encouraging the use of the non-Twitter services.
3. Once have a good traction, penalize Twitter post to further push non-Twitter adoption. Eventually remove Twitter support completely.
4. Profit??