> unreasonable "safety standards"
Are these the same safety standards that cause apple predictive text to refuse to recognise the cuss words I a grown adult use and have to go back and fix over and over again. Ducking stupid if you ask me.
Are these the same safety standards that cause apple predictive text to refuse to recognise the cuss words I a grown adult use and have to go back and fix over and over again. Ducking stupid if you ask me.
[0]: https://www.theverge.com/2018/11/20/18104366/tumblr-ios-app-...
So yes, Apple may only have required Tumblr to more effectively moderate to prevent child porn, but from a business feasibility point of view the practical way to do that was ban all porn.
Safari works amazingly for small websites, but for websites with infinite scrolling like Tumblr and Twitter, it becomes unbearably slow after the first hundred or so posts. Historically, Safari is slow to adopt new web features, and it STILL doesn't have web push notifications (and more).
You can run these same websites on Android Chrome just fine, even on a lower-powered Android phone. I'm not sure if they're using APIs that need to be polyfilled on Safari, or if Safari is just trash.
At this time, I'm convinced that if Apple allowed other browser engines on the App Store, this would not be a problem at all, not that I can test it out anyways.
So, yes, Apple still has a say.
However, curiosity requires that I ask what/how/why does any of that affect mobile-first web deployment in away that it is not addressed when a large chunk of that mobile use is broken? If you program yourself into a dead end, back up and take another turn.
Oh, it is easier in a mobile native where you get the benefit of hoovering up personal data on all of your users? Gee, let's not expend effort to make something work universally, let's instead take the easy route and make money on the side too. The fact that losing this large share of users because of one type of content is not enough of a decision to go the other route shows just how much money there is in the hoovering of data.
Still putting the blame on Tumblr.
So, to me, Tumblr's website is already the main point of access, and these performance problems don't exist on Firefox or Chrome. I'm not talking about server-side response times, I'm talking about the time to render posts on the client. I find that a lot of times, after scrolling, you have to wait a few seconds before you see anything but the blue background that Tumblr has.
So, no, I'm going to pin it on Safari if (even) Firefox can deal with it.
Yahoo runs one of the biggest ad networks in the world, and you need to register to use Tumblr. They as already have everything they need to track you right there.
A mobile app in many circumstances reduces the data tracking (see this whole discussion about how effective Apple's do not track is because of their monopoly powers).
Just because Apple made it harder doesn't mean they made it impossible. There's a reason so many places work on making apps for multiple platforms (at least 2) rather than a unified web experience. There are benefits beyond serving a webpage in a native app, and they all want those benefits. Stick your head in the sand and deny it all you want, but it still happens.
That's absolutely not true, even if the web developer implements this in the Dumbest Possible Way. Please point me to an example page and prove me wrong.
You'll be able to see it take seconds to render at a time. This is true on an M1 Mac, as it is true on an A15 iPhone and M1 iPad.
I scrolled through 300+ stories (or whatever they're called on Tumblr) and it still hasn't slowed at all. Not sure what you're seeing.
On M1 Max with Safari 15.5, it took me about 40 seconds of fast scrolling to get it to start stuttering occasionally. Then, another 30 seconds to get it to start blanking out for a second at a time. And finally, another 30 seconds to get it to start taking seconds to render. I won't give the number of posts before it started lagging because I don't know the exact number.
On my phone (iPhone 13 Pro Max, albeit on the iOS 16 beta), it takes Safari about 15 seconds of scrolling before the scrolling drops to around 40fps from what looked close to 120fps. Then, another 20 seconds to start seeing things rendering halfway before jumping around and then rendering the correct post. This isn't necessarily a fair comparison due to the usage of beta software, but even on an M1 on production OS software it doesn't seem to be much better. Chrome 102 on macOS handles the exact thing that I did without any problem at all.
It's especially bad when you have a lot of videos on your dashboard. If you only have image posts, it might take a bit longer to start stuttering.
This has been the case for years, so it's nothing new. I remember this being a problem almost a decade ago, on an 4th generation iPad with the A6X SoC. Things have improved since then for sure, but those it's probably mostly hardware improvements that's helping.
I'll accept blaming Twitter's horrible performance on its use of React Native Web, but not Tumblr.
This really sounds like one of those issues a dedicated person finds where the devs look at it and say no reasonable user would ever do this. The issue if not closed as "won't fix" gets deprioritized so low that it never gets looked at again. Even as a dev, I'd not have the patience to recreate the problem. It's just such an outside edge case from expected behavior/usage that I don't even know what to say in response.
I don't think you're in the target audience of Tumblr, which is fine.
I honestly worry for people that do. There's something sad to me about people that do.
Is it a memory leak in Safari? Is it a framework issue? You've started us down the path to a thing, but then you didn't finish telling us the thing.
Good. These features need to be supported by browsers for an extremely long time and Google is trying to force garbage under the guise of "standards." I hope Apple continues to fight against the ridiculous power hungry feature creep.
Once I’m down about 50ish posts on my feed, hitting back from a post to get back to the feed seems to have around a 25% chance to quickly throw a “Safari has detected a problem” error and force a refresh - sending me back to the top of the feed. And this is on an iPhone 12 Pro Max so it’s not like the hardware is out of date.
I primarily blame Safari, but on some level I think Twitter is aware of the problem and has no intentions of fixing it. The mobile Twitter site is purposely designed to make it nearly impossible to open a tweet in a background tab if it doesn’t have an image (the browser tries to select text on a long press). That’s clearly something Twitter could fix if they wanted to.
(I've got an oldish phone, but it performs fine on every website I ever visit except Twitter.)
Tested in Android Firefox on https://mobile.twitter.com/home.
You mean Gecko or Blink? WebKit is really not the problem. Web Developers' strict compliance to only make sure their site works on Windows may be part of it.
Strange. This is exactly how I use Twitter on my i-devices, and it's perfectly smooth.
Seems pretty simple.
It's nothing more than ammo that corporations use against each other in the fight for dominance, or sometimes, with the help of cooperative media, against politically disfavored sites like 4chan. In all my time browsing 4chan, I have not once seen child porn, though I did see posts 404'd for having contained child porn. Yet despite their efforts, any time the media talks about 4chan, they will introduce it in the same breath as child porn.
In short, child porn has become nothing but a tool for corporations fighting for dominance, or a fnord to tell the masses to stay away. And in all of this no-one gives a crap about the children, since they rarely spend even a word talking about tracking down the uploaders or creators of said porn (i.e. they say a site "has child porn", but not how fast it is removed, or if the site gives the IP of child-porn uploaders to the police, or anything beyond trying to establish in the viewer a bad site <-> child porn association).
Aren't there legal requirements in place for this stuff, at least in the US?
But they're not normal words. They're expletives. If they have their own category, they're not "normal words."
iOS doesn't know a lot of the medical words I use for work, either. But I don't moan about it on social media.
Like adjectives, nouns, verbs, adverbs, or any other of many word categories?
They are normal words understood by everybody, if not used by everybody, unlike your medical jargon.
The idea that expletives are not normal words is wrong. Common people have always spoken plainly. They would not have called their asses "bottoms" etc.
Given that auto-correct is a function of software then yes, word selection is part of Apple's business. There are two parts to the solution. The technical aspect is probably not at issue. The socio-political component is going to reflect mainstream corporate culture and probably not meet many corner cases. The significant choices aren't Apple's to make sense they will bow to the anathema dictates of social and political power: such as Winnie the Poo in certain Chinese contexts or Swastikas in German ones.
It's no way to treat adults.
The question is "as a parent, would you buy an {x} phone for a young family member that suggests profanity?"
As an adult, you can go in and add the words that you want to use yourself... however, do you want profanity to be a default suggested word for children in your household?
Realizing that the demographics of HN tends to the more technically literate, removing the all the words you don't want your children accidentally sending to their teachers wouldn't be a big issue, however as most of the population isn't as technically literate the "it just works" mentality for digital appliances would mean that most of the population that has a child who may use the phone would likely opt to one that is more proper and correct in its limited word choice.
Kids have Android phones, so yes, it is clearly the case that most parents have no problem with this.
Not "can you go in and unblock profanity suggestions" ( https://www.laptopmag.com/articles/disable-android-offensive... ) but rather "is this the default"?
That seems eminently reasonable to me, without being "safety standards".
Yes, modern English is certainly saltier than what people pretended it was for the last century or so, but the line that Apple took seems to be the right line (allow offence without correction, do not suggest offence by default).
There are many things on which I disagree with Apple’s stance (I think that Apple should allow pornographic apps in the store, but that those apps should have tighter controls on them to prevent some of the scammiest behaviours reported against pornographic sites; I also think that Apple should be doing a lot more to prevent abuse of the pricing tools that it does have).
You can of course install any keyboard you want with basically any behavior you want here.
Edit: Never mind, it's "Block offensive words" under "Text Correction". Easy to find, strange I never noticed it. Thanks!
And it ALWAYS refuses to type "fuck" when you do glide / swipe typing.
The soft keyboard is always using some heuristics to identify which characters you intended to type. In most cases it's quite accurate, but in this case it seems like it's over-counting the probability you would have typed "duck" or "ducking" by a fairly wide margin.
Only related in the sense that Apple takes steps to prevent surprise adult content. Just as porn is obviously trivial to consume with Apple devices, autocomplete can happily suggest your favorite salty language.
https://www.macworld.com/article/673861/how-to-stop-an-iphon...
Sometimes the agenda goes a bit too far.
https://www.macworld.com/article/673861/how-to-stop-an-iphon...