[HN Gopher] Outdated vs. Complete: In defense of apps that don't...
___________________________________________________________________
Outdated vs. Complete: In defense of apps that don't need updates
Author : ingve
Score : 301 points
Date : 2022-09-26 19:13 UTC (3 hours ago)
(HTM) web link (vivqu.com)
(TXT) w3m dump (vivqu.com)
| crazygringo wrote:
| Hate away, but in this case I'm on Apple's side here. The author
| may be the exception where no updates are actually needed, but
| that does seem to be the exception. In my experience, most iOS
| apps I've tried downloading that were last updated 2-3 years ago
| simply don't work.
|
| Apple requires an update in the past 3 years or else a minimum
| threshold of downloads. Presumably the latter is required so
| there are simply enough newer reviews to indicate whether it's
| broken (lots of 1-star) or not. These seem like pretty reasonable
| indicators that it's still working.
|
| > _My old code simply did not work anymore with the latest
| versions of Xcode. So I had to spend four hours on Saturday
| upgrading all my platform libraries simply so that I could
| compile the damn app._
|
| Honestly that's just good hygiene. Because if they waited another
| 2 years, it might have taken 4 days to get the thing working. New
| versions of libraries come with all sorts of improvements,
| whether it's for accessibility or security or a hundred other
| things.
|
| It doesn't seem unreasonable to me that if you're maintaining
| software in a public app store, you should be able to compile it
| semi-regularly with new versions of packages.
| lapcat wrote:
| > Presumably the latter is required so there are simply enough
| newer reviews to indicate whether it's broken (lots of 1-star)
| or not. These seem like pretty reasonable indicators that it's
| still working.
|
| You think App Store ratings and reviews are accurate?
|
| They're incredibly easy to fake and buy. Scam artists are doing
| it all the time.
| masklinn wrote:
| > In my experience, most iOS apps I've tried downloading that
| were last updated 2-3 years ago simply don't work.
|
| Not sure what category of software that was but e.g. for games
| it's usually not an issue. I used to have a bunch of games and
| game-adjacent software from the first AppStore year, we're
| talking the time when you'd pay a buck for a virtual rain stick
| which's use the accelerometer.
|
| They kept working until the 64b switch killed them. Rebuilding
| them would undoubtedly have been difficult for the author even
| if they'd not moved away from them, but because those'd use
| only minimal is features (raw-ish inputs, and setting up
| opengl) there's basically nothing to break which would not be
| flagrant.
| musicale wrote:
| I also had many games killed off by the 64-bit switch (on
| both iOS and macOS), but even after that a number of games
| that still worked were removed from the app store.
| TedDoesntTalk wrote:
| Games are definitely "complete" after a while., sometimes
| on first release. If they continue to work on the OS, the
| only reason Apple is dropping them is because they want the
| developer to give them another $99. The busywork this
| creates is a headache for everyone except Apple.
| arcticbull wrote:
| $99 from a few developers is meaningless to both Apple
| and the developer of a game. It's like 40 minutes of
| wages for an average engineer. Apple doesn't want to have
| to support old bugs and poor API choices in perpetuity.
| TedDoesntTalk wrote:
| What makes you think it's only a few and not large scale?
| And why would forcing a developer to update their
| feature-complete game result in stopping support of "old
| bugs and poor API choices"? There is no requirement to
| update the API level. Read the article.
| arcticbull wrote:
| Simply rebuilding and resubmitting the app with a new
| version of Xcode will yield a significantly different
| binary artifact today than a few years ago.
|
| It isn't necessarily about API level, it could be (from
| time to time) about going from arm32 to arm64, to adding
| better-optimized builds for new microarchitectures,
| getting bitcode that's recompiled by Apple to support app
| thinning. Apple may deprecate or remove APIs from time to
| time that should also be addressed.
|
| That there wasn't necessarily, specifically, a change
| this time doesn't mean that this program isn't about
| supporting that over time. It's much easier to make such
| changes if developers are in the habit of periodically
| making updates vs. being told to make a breaking update
| out of the blue.
| scarface74 wrote:
| You really think the $99 a year from developers would
| incentivize anything?
|
| And before you quote the number of "registered
| developers", all of those aren't _paying_ developers.
| TedDoesntTalk wrote:
| 1,000,000 paying developers is $99 million in revenue --
| every year. This is easily an incentive for Apple.
| scarface74 wrote:
| In your grandparent comment, you said it costs everyone
| but Apple. Apple has manual reviewers. It would be much
| cheaper if all those apps didn't have to go through the
| app review process. You think Apple changes their APIs
| willy nilly just to collect $99 a year?
| nemothekid wrote:
| > _Apple tells me I could have avoided all this pain if my app
| was being downloaded above a "minimum download threshold". The
| policy is completely silent on what this download number needs
| to be to avoid getting flagged as outdated-is it hundreds or
| thousands or hundreds of thousands of downloads a month?_
|
| I think this is a fair policy as well. From Apple's POV how can
| they ensure many apps in the app store still work on the latest
| phones? If the developer has been updating the app, they can be
| relatively sure. If the developer hasn't, but the app continues
| to be downloaded with success they can also be sure the app
| works. But for an app the developer has (seemingly) abandoned
| and and nobody downloads? It's most likely broken. You could
| argue that that Apple should test the app before sending such a
| message but I think it's probably likely that (1) the majority
| of apps that are abandoned are broken and (2) the developers
| don't actually respond. It's easier to tell all the devs to get
| up to speed and those that actually care will submit the app
| for review (even if all you have to do is change a version
| number).
|
| What actually sucks is if you have to rewrite parts of your app
| because even though the iPhone 22 Pro Max Plus w/ Turbo &
| Knuckles supports the same SDKs as the iPhone 4, Apple won't
| let you resubmit your app as is.
| yamtaddle wrote:
| It also makes sense because it might not be a good idea to
| apply the same criteria everywhere. In an app category with
| 10,000,000 downloads per month, an app pulling 500 downloads
| a month might be a drop-worthy also-ran that's mostly just
| directing a few people away from better options & cluttering
| results. In a category with 1,000 downloads a month, the app
| with 500 dl/m is likely _the_ best and most-popular app in
| that category and dropping it would be tantamount to dropping
| the whole category.
| bambax wrote:
| Backward compatibility is Apple's job, not developers.
|
| (This debate is as old as computers, but I'm strongly in
| Raymond Chen's camp.)
| musicale wrote:
| I agree. Unfortunately they've abdicated their responsibility
| and dumped the maintenance/compatibility burden upon
| developers.
|
| It seems like a multiplicative trade-off: Apple saves a small
| number of hours but offloads a support burden onto thousands
| of developers.
|
| I think you have to be careful about this. Apple benefits
| from lower costs and having more time to improve the
| platform; but developer time/focus/creativity is also being
| taxed by a constant support burden.
| andrewxdiamond wrote:
| > It seems like a multiplicative trade-off: Apple saves a
| small number of hours but offloads a support burden onto
| thousands of developers.
|
| Backwards compatibility is not a trivial effort, and can
| severely constrain the future evolution of a product. Keep
| in mind you're asking for a completely backwards compatible
| embedded device OS. Being willing to make breaking changes
| is part of why Apple's software is the quality that it is.
|
| If you want a counter example, Windows is notorious for
| strange undocumented behaviors and special case handling.
| These are consequences of Microsofts choice to fully
| embrace backwards compatibility. This leads to a
| complicated platform that is continually more and more
| expensive to maintain, polish, and secure.
|
| That expensive polishing cost is what tips the scales here
| for Apple. Backward compatibility can get in the way to get
| the level of polish that they call acceptable.
| alerighi wrote:
| Android to me is better regarding of backward
| compatibility. Of course everything is easier since it
| has a much more flexible architecture, being based on
| bytecode and a JVM (contrary to iOS where applications
| are actual native binaries). The problem is that iOS is
| not all that well designed in that regards.
|
| > If you want a counter example, Windows is notorious for
| strange undocumented behaviors and special case handling.
| These are consequences of Microsofts choice to fully
| embrace backwards compatibility. This leads to a
| complicated platform that is continually more and more
| expensive to maintain, polish, and secure.
|
| Yes, and macOS (and iOS) a POSIX operating systems that
| maintains backward compatibility with something from the
| 80s. In that regards Windows is much more modern.
| arcticbull wrote:
| Hard disagree. Letting your platform stagnate by ossifying
| bugs and poor API choices is not what I want to see from any
| platform provider, and I for one am happy Apple is
| aggressively pruning the old to make room for the new and not
| allowing themselves to be beholden to past mistakes.
|
| I'm sorry this developer spent a couple hours hitting "build"
| until their app started working. If they'd done it earlier it
| would have been far less painful. Their sacrifice improves
| the community.
|
| I say this as an iOS engineer since like 2012 and a macOS
| developer since ... 2004?
|
| Carbon [1] should never be allowed to happen again. If you
| really want an old system, you should be allowed to
| virtualize it, but the world must move forward.
|
| [1] https://en.wikipedia.org/wiki/Carbon_(API)
| guhidalg wrote:
| I don't understand this comment, do YOU actually ship
| breaking changes to your users and expect them to continue
| using your code or programs? Just because Apple does it
| doesn't mean it's actually a good idea.
| arcticbull wrote:
| I, like anyone with a project sporting a major semver
| number >1 definitely ship breaking changes to my API
| customers.
| guhidalg wrote:
| Can you not? I understand sometimes you absolutely need
| to change a signature or deprecate a feature, but that
| should absolutely be the exception and not the norm.
|
| Going back to the original post, I find it ridiculous
| that Apple regularly ships breaking changes (to their
| APIs) and developers just put up with it. In my minds,
| it's like being in an abusive relationship where you
| think if you try a little harder and stay up to date with
| the latest API version maybe Apple will treat you better
| (they won't). Apple can get away with it because they own
| the whole iOS/macOS tower top-to-bottom, but if you want
| to build trust with your users breaking changes should be
| the absolute last choice.
| desindol wrote:
| Nope, cull it all. I don't need zombie apps in store because
| one guy in Australia really likes it and I really don't need
| 10 years backward compatibility in OSes. This whole debate
| let ie6 go on for over 21 years... 21 years because
| businesses couldn't be asked to update their apps. Sorry if
| you need old shit emulate it.
| trap_goes_hot wrote:
| I'm advocating for me, and users like me, not for the
| interests of a greedy corporation. I just want the things
| that I paid for to continue working. I don't want to re-buy
| things just so Apple can line their own pockets. I don't
| want to chase developers to provide updates, or if they
| have gone out of business, be stuck. I use technology as a
| tool to get stuff done. I don't need Apple to come and
| disable my investment in software.
|
| https://lkml.org/lkml/2012/3/8/495
| NavinF wrote:
| I'd be on board if Apple allowed alternative app stores or
| internet downloads. Right now you either get curated or
| nothing.
| newtritious wrote:
| This is just wrong. Some older APIs are simply insecure or
| inefficient for example, and of course there are things that
| apps must now ask permission for where they didn't in the
| past.
|
| Apple can't make these things compatible, nor should they
| try.
| scarface74 wrote:
| I know this isn't an issue for the author. But for Apple to
| keep backward compatibility for ever, they would still be
| using die space for 32 bit support and have duplicate
| versions of every shared library both in memory and on disk.
|
| Last time I checked, because MS worships at the alter of
| backwards compatibility, there are nine ways to represent a
| string in Windows in C and you constantly have to convert
| between them depending on which API you're calling.
|
| Every piece of code in your operating system is another
| vector for security vulnerabilities and something else to
| maintain and in Apple's case port to a new processor. How
| slow has Microsoft been entering new markets because of the
| albatross of legacy code?
| naniwaduni wrote:
| Worse, developers need _forward_ compatibility. Predicting
| the future is widely considered harder than inspecting the
| past.
| musicale wrote:
| In theory if you follow Apple's guidelines then you should
| maximize your app longevity; in practice Apple is going to
| break you eventually, and quite possibly in the next OS
| release.
| tonmoy wrote:
| Unreasonable backward compatibility is how we end up with
| windows vista
| musicale wrote:
| Windows Vista was painful, but consider that:
|
| 1) Compatibility wise it wasn't worse than macOS Catalina
| or iOS 11, which both killed off 32-bit apps; actually a
| typical iOS release is probably worse than Vista in terms
| of backward compatibility
|
| 2) Vista's security improvements (such as sandboxing device
| drivers, requiring app permissions, etc.) were beneficial
| and persist to today - and were arguably the predecessor to
| modern app permissions systems in macOS and iOS (and
| Windows 10/11)
|
| 2a) Microsoft eventually largely addressed compatibility by
| providing an XP compatibility mode (really an XP VM); they
| could have/should have managed this better
|
| 3) Vista got the UI for app permissions wrong, and users
| hated it; I think Apple did it better but Apple is
| generally better at UI and also had the chance to learn
| from Microsoft's mistakes.
|
| At the end of the day, Vista's woes were largely from not
| paying enough attention to backward compatibility, combined
| with poor UI design. It was a rough transition, but
| Microsoft seems to have learned somewhat from the
| experience (although Windows 8 also had some UI issues.)
| scarface74 wrote:
| The tradeoff with killing 32 bit apps was that Apple
| could remove support for 32 bit code in ARM processors.
| Apple knew they were moving to 64 bit ARM processors.
|
| But should Apple have kept support for PPC support
| forever? 68K? Why not keep a 65C02 emulator around so I
| can run Oregon Trail from the 80s?
| musicale wrote:
| > Why not keep a 65C02 emulator around so I can run
| Oregon Trail from the 80s?
|
| Sounds good to me! Pretty sure Apple 2 system software
| and an emulator would only be a few megabytes, and it
| would be awesome as something you could install for free
| like GarageBand etc.. Apple might also be able to acquire
| the rights to a bunch of classic Apple 2 apps and
| games...
|
| Maybe we can convince Apple to do it for their 50th
| birthday. Or maybe a Mac emulator for the 40th
| anniversary of the Macintosh in 2024. ;-)
| matchagaucho wrote:
| Agreed. Apple is not asking for more features, but a recompile
| of the app against the latest iOS and SDKs.
|
| That's generally a good practice as buffer overflows and all
| kinds of entropy accumulates on an OS.
| kkfx wrote:
| Mh, changing the "ecosystem" so much means the ecosystem is not
| stable, witch means is a crappy mass of bugs/a working
| prototype not a commercial product.
|
| Oh, I like of course _innovation_ but if we talk about mobile
| stuff, so something tied by choice to hw, their real update
| rates behind security related patches, should be very calm.
|
| Anything must evolve to be alive, but also anything must NOT be
| stressed to change just some crap to prove that something have
| changed. That's not evolution.
|
| Beside that, I fail to see any tangible improvement in ALL
| modern software to a point that I almost quit using mobile
| crapware of any vendor and kind, for real. I can't avoid it
| completely, unfortunately, but that's is.
| newtritious wrote:
| Quite a few changes over the past few years have been
| reducing access to data that can be used for fingerprinting,
| and requiring apps to ask permission for access to user data.
|
| This is squarely the fault of developers abusing the users
| trust.
| alpaca128 wrote:
| > In my experience, most iOS apps I've tried downloading that
| were last updated 2-3 years ago simply don't work.
|
| The linked article already answered this: For
| instance, the App Store could factor in: - App Store
| ratings and reviews - Active developer membership
| - Historical behavior of the developer (ie. updating other
| apps) - Number of crashes - Number of
| active sessions, especially for the latest devices and platform
| versions These are all metrics that the Apple already
| automatically tracks
| scarface74 wrote:
| Apple just like most sane platforms have a deprecation
| policy.
|
| First they deprecate APIs and then remove support entirely.
| She said herself that she had to make changes to update her
| code to the latest SDK.
| fny wrote:
| You know what doesn't have this problem? Web apps. I have a
| site up from 2001 that still functions perfectly.
| stonemetal12 wrote:
| I doubt it. Web browsers of today can't pass the old acid
| tests because the spec changed.
| t_mann wrote:
| Frankly, isn't that just what you signed up for as a mobile
| developer? The WorldAnimals app would probably have worked
| perfectly fine as a web app, but then the author would have had
| to figure out payments and discoverability himself. That's what
| the App Store offers, and in exchange Apple gets tremendous power
| to tweak every nook and cranny to maximise their profit. I'm sure
| Apple has good commercial reasons for the process that the author
| has experienced.
|
| I think the real answer here isn't to try and beg Apple to be
| nicer to the small fish, but to instead use the "old", non-walled
| version of the web.
| NaOH wrote:
| As a user, there are two issues I could face from this type of
| culling. First, I keep older devices--maybe just for RSS or news
| apps or podcasts or in-car music or video players. Relatively
| simple, straightforward uses. If I have additional uses in mind,
| apps won't be available. Similarly, the same would be true for
| someone who wants to let a child use an older device for
| something like games.
|
| The other issue is the number of iOS hiccups which can lead to
| support documents saying to reinstall the OS. Doing that will
| make older, removed apps unavailable after reinstallation of the
| OS if the user relies on iCloud backups. This risk necessitates
| iTunes backups to insure such apps remain available after
| reinstalling the OS.
|
| I doubt a situation like this contradicts the overall value of
| the culling. But I do know it has an effect on me and there are
| some people--certainly, a small number--who will lose apps
| because of the shortcomings in iCloud backups.
| alberth wrote:
| Don't forget "Feature Complete".
|
| It's a real thing especially when you're building something under
| the unix philosophy of "do one thing only, really well".
| dkarl wrote:
| > The impact of the App Store Improvement policy is nonexistent
| for VC-funded companies.
|
| Not true. More often than not, our iOS releases get delayed hours
| if not days, while our long-suffering iOS lead patiently walks
| yet another green reviewer through the policies and our previous
| interactions with reviewers to convince them that our app is in
| compliance. Among other things, our app repeatedly gets flagged
| for failing to comply with rules that don't apply to it. This is
| usually resolved with a simple message to the reviewer, but
| depending on the turnaround, that can effectively add a day to
| the time it takes to get a bug fix out.
|
| Dealing with these bogus issues probably accounts for 5% of the
| productive time of our iOS lead. And this is despite keeping our
| release cadence slow (every two weeks except for the most
| critical bugs) and after we've made many reasonable low-to-medium
| effort changes in our app to stop triggering false positives in
| their tools.
|
| God help us if Apple ever went the Google route. Apple reviewers
| might be inexperienced and undertrained, but at least they're
| human and capable of talking through issues.
| ineedasername wrote:
| _> I think the asymmetry of App Review is still lost on Apple.
| For indie developers our hopes and dreams (and sometimes our
| finances) hang in the balance, for the App Review team it's just
| another app rejection among tens of thousands. I know they think
| they get it, they just don't._
|
| I really don't think it's lost on Apple or the app review team.
| They simply have no incentive to change and a captive audience in
| both developers & app users/buyers. Better customer service (to
| devs) on the app review process when there are issues, and
| continuing support for older SDK's, cost time and money and Apple
| does not see the value in that investment.
|
| Absent competition there's also no pressure to change this.
| There's effectively a duopoly in mobile software between Apple &
| Google. They don't even need to explicitly communicate with each
| other to act as a cartel, they just need to silently follow each
| other's lead.
|
| Android is at least marginally better for allowing-- through a
| few scare-tactics hoops to jump through-- sideloading of apps,
| but I don't consider that sufficient competition to overcome the
| duopoly label. Neither is Android's allowance of alternative app
| stores, no more than MS allowing users to install alternate
| browsers was sufficient to overcome their uncompetitive practices
| when it came to IE. The primacy of the Play store on initial
| setup & its extremely deep integration in the OS is difficult to
| overcome.
|
| Alternatively, I am slightly conflicted on this due to the
| security aspects of app installation. Mobile certainly isn't
| perfect, but the prevalence of malware seems significantly
| reduced from what is seen in PC's. (well, windows. MacOS is not
| as bad as Windows, but I've always considered that to be a
| produce of it's lower market share & therefore lower cost/benefit
| ratio for attackers.)
| faeriechangling wrote:
| I don't know why Apple is doing this if they want to maintain
| their monopoly, I only see them throwing fuel on the fire of the
| breaking up of the App Store for some pretty marginal benefits
| for themselves. They are literally targeting the smallest and
| poorest developers explicitly.
| GuB-42 wrote:
| Hey, Apple, people still play Super Mario, they didn't change a
| single bit since it was released, 37 years ago.
|
| But there is one reason I somehow understand Apple stance. First
| is security, almost all apps are online now, and new
| vulnerabilities are found regularly. Super Mario has bugs, be no
| one cares, in fact, speedrunners have fun with them, because a
| NES is not online and there is nothing sensitive in there to
| begin with. Second is Apple's own fault: they break their own
| system and want you to make sure you keep up.
| bena wrote:
| I don't think the Super Mario comparison is entirely fair here.
|
| Super Mario Bros runs on a single piece of unchanging hardware.
| Even when you play it on any other platform, you're playing it
| through an emulator designed to mimic the original hardware.
|
| And that's the case with all video game consoles. Even when the
| physical hardware changes, you're given the guarantee that it
| won't be breaking to the software. The few times that has not
| been the case has been notable.
|
| iOS devices don't have that guarantee. The hardware can have
| breaking changes. You software now has to contend with the fact
| that there is no guarantee that certain features may or may not
| be present. Things that were previously not customizable, now
| are. If you want your software to run on the latest iOS, it is
| at least partly your responsibility to ensure that it does.
| meesles wrote:
| I couldn't really accept this blog post because the author
| doesn't even realize they benefit from Apple's walled garden:
|
| > Most people are trying to build well-designed, useful mobile
| apps
|
| and then proceeds to say how the review process is not helpful
| because they don't weed out many malicious apps. First,
| confirmation bias. Second, do they have any idea how things are
| in Android land? It's a constant struggle against nefarious app
| devs trying to abuse new technologies or means of getting
| ad/install revenue. It's one of the things I like the least about
| the ecosystem I use.
| WesolyKubeczek wrote:
| In an ecosystem like npm, having such thing is next to
| impossible. The useful libraries that don't depend on anything
| else from npm are rare, and those that are need to review their
| lockfiles and run npm audit and whatnot every once in a while,
| even if their own code doesn't change. Otherwise it's quite a
| pain to integrate them with newer codebases.
|
| In any ecosystem at all: if it speaks HTTPS, it's either never
| complete, or it ceases to function past some date.
|
| I get the sentiment very much, but there are cases when you can't
| have nice things.
| Kwpolska wrote:
| Eh, this is Apple you're talking about. They don't know what
| backwards compatibility means, and your app might randomly break
| on the newest version of iOS. Or it might be slightly ugly around
| the Dynamic Island(tm) and Apple users would hate that.
| musicale wrote:
| > They don't know what backwards compatibility means
|
| Platforms are supposed to absorb developer pain, but Apple
| offloads a continuous and multiplicative update burden onto all
| of their developers.
| Gigachad wrote:
| Because Apple prioritises the best user experience.
| 0x37 wrote:
| I've personally witnessed several unnecessary and costly
| refactorings in my job that were done due to this weird
| perception the blog is talking about. All those weeks and months
| that were spent removing a perfectly fine tool that was working
| without issues.
| layer8 wrote:
| God, the UX in that karalof video is so much better than what iOS
| has become today.
| renewiltord wrote:
| In a world with security concerns, can anything be complete?
| detaro wrote:
| yes. (especially but not only on mobile, where the platform is
| responsible for a lot of it)
|
| Security concerns are very clustered around limited attack
| surface, that many apps just don't have.
| hmcamp wrote:
| Yes. The ls Unix command.
| renewiltord wrote:
| Haha you got me, but I wouldn't be surprised if there were
| Unicode issues etc as you have to support modern filesystems
|
| Like this https://www.exploit-db.com/exploits/33508
| Gigachad wrote:
| I'm not sure the ls command has to do much if anything to
| support new file systems since the file system driver
| should present a standard interface for them.
| User23 wrote:
| I've never even heard of anyone getting promoted by saying "this
| app is perfect, let's leave it alone except for bug fixes." The
| overwhelming incentive for everyone involved in most commercial
| software work is to continually make changes, necessary or not.
| jmbwell wrote:
| Looking at the metrics Apple tracks in the App Store, it seems to
| me that "engagement" is all that really matters. You could have
| some huge number of happy users, but if they open the app only
| occasionally, you get numbers in red. Or you could have an app
| that solves an important issue but only for a small number of
| users, and you get numbers in red. If you're not releasing hits
| that people use all the time, you sink. If tons of people don't
| spend tons of time in your app, you sink.
|
| Author complains about the time required to update libraries, and
| that's an aggravating process, but that's just an unfortunate
| part of maintaining an app. The real issue, again it seems to me,
| isn't that you have to do a lot of work just to increment the
| version string; it's that, ultimately, modern content ecosystems
| are designed according to engagement-driven revenue models. And
| solid, simple, quiet, long-lived, useful or fun little apps
| simply can't thrive when all the sunlight is blocked by towering
| marketing-tech giants.
|
| IMHO.
| klabb3 wrote:
| > Looking at the metrics Apple tracks in the App Store, it
| seems to me that "engagement" is all that really matters.
|
| This has been the name of the game in ad tech like fb, Google
| and social media in general. I think two worlds are clashing
| with each other, where consumer tech is somewhat aware of the
| problems around mindless scrolling and addiction, but the
| growth & engagement mindset of the 2010s is cemented in the
| culture. Apple has little reason to follow this model because
| they primarily make money from selling hardware. Having a
| software platform that protects the user from this crap is a
| competitive advantage against Google, who depends on ad-based
| revenue. Apple seems to have an identity crisis, fearing they
| lose out on sweet subscription fees and ad revenue, now that
| most apps are free. This in turn is creating conflicts of
| interest, where they end up fighting their own customers.
|
| If regulators would bark and bite harder around anti-
| competitive behavior, it might actually force corporations to
| focus on what they're good at instead of everyone building
| their own mediocre walled gardens that grow like a cancer and
| eats the company from within. At least, that's my wishful
| thinking..
| kitsunesoba wrote:
| Additionally, updating libraries periodically is inescapable
| for any app involving network connections or handling arbitrary
| user content, because doing otherwise means exposing your users
| to vulnerabilities.
|
| Fully offline, totally self-contained apps are a different
| matter, but those represent an increasingly small percentage of
| apps.
| armchairhacker wrote:
| I hate to see a piece of open-source software abandoned and
| broken. But I love to see a piece of software "abandoned" and
| still working because it has been designed for long-term use and
| simply doesn't need updating.
|
| That is how open-source grows. Because you can't grow a codebase
| if you have to keep updating and fixing what you've already done.
| As you have to keep updating and fixing stuff, new progress slows
| and eventually stops. It's the same for "codebases" like
| ecosystems/package repos and open-source in general
| TillE wrote:
| This is another case where Apple fundamentally doesn't "get"
| games. They had a plan for clearing out crap from their store
| which probably sounded reasonable, but nobody even thought about
| an entire class of programs.
|
| Lots of stumbles and missed opportunities - like, what if they
| had actually been serious about making the Apple TV a Wii-style
| games console? They have the hardware expertise to do that at a
| reasonable cost, but they just have no idea about the market, and
| apparently no desire to learn.
| themagician wrote:
| Oh, they get it.
|
| Apple products very much have a time and a place. Their plan is
| recurring revenue. Something that happened 3 years ago is
| almost entirely irrelevant to them. It's true with both
| hardware and software.
|
| Wii-style games on AppleTV would not be a win for them. They
| don't want to sell a few million copies of Wii Sports once
| every 3-5 years. They want you buying a new 99C/ game at least
| once a month. They want you spending $5-10 in micro-
| transactions a month. They want you subscribed to AppleOne for
| $15-30 a month. They want you to buy a whole new iPhone every
| 2-3 years and start the process all over again with some new
| AirPods, cases and bands in between.
|
| Apple doesn't want to sell you a new game for $59 every 2
| years. They want to sell you what amount to an average of $59
| worth of goods and services a month... forever. And while that
| sounds like a lot, that's a low target. If you have your TV
| subscriptions through Apple and Apple Care you can _easily_ be
| contributing $100 /mo or more to Apple's bottom line.
| musicale wrote:
| I understand that Apple is trying to deal with the sort of
| shovelware/accumulation problem that the Wii had, but the
| blanket approach of culling games based on release date seems
| wrongheaded.
|
| If Nintendo took that approach then they'd end up throwing away
| Super Mario Odyssey and Zelda: Breath of the Wild.
| spullara wrote:
| Probably not since they get plenty of downloads...
| stabbles wrote:
| On a related note, I feel that some websites at are a point where
| they're complete, and adding new features makes the experience
| worse.
|
| Take Github: to me it feels that it's now at an optimum where
| adding new features that make it more social or more "fun" would
| simply make it worse.
|
| Similarly Youtube: tons of good material, user interface is fine.
| Then they introduced shorts, and to me it feels like these type
| of video's are simply not part of youtube's identity, adding them
| only makes it worse.
|
| At some point it might be best to stop adding new features and
| just agree that things are fine now as they are.
| koreth1 wrote:
| Surely it's possible for GitHub to add features that aren't
| related to making it more social or "fun," though? For example,
| they could improve their support for stacked PRs in a number of
| ways; that's an area that is far from fine at the moment IMO.
| _dain_ wrote:
| they could show the linecount of each file in the repo browser
| _jal wrote:
| Apple is starting to remind me of auditors, but instead of trying
| to keep people honest/push trendy practices, they're pushing
| whatever's trendy in Apple's management class this month.
|
| When do we get to the point of companies hiring "review
| specialists" who used to work for Apple?
| jaywalk wrote:
| Anyone who could afford a "review specialist" is probably
| already getting the white glove treatment this post describes,
| and wouldn't actually need one.
| plorkyeran wrote:
| > So I had to spend four hours on Saturday upgrading all my
| platform libraries simply so that I could compile the damn app.
|
| I sort of assume this is the actual point? Apple presumably wants
| to drop support for older versions of the SDKs, and that requires
| that app developers update to the newer versions. I think you can
| make a reasonable argument that dumping work on third-party
| developers to simplify things for themselves is bad, but the
| author's belief that it was simply pointless busywork is probably
| incorrect from Apple's perspective.
|
| I suspect the minimum download threshold to be exempt from this
| is _very_ high. Maintaining backwards compatibility for a small
| fixed set of apps doing things an old way is a categorically
| different problem from maintaining backwards compatibility for
| every app out there.
| dahfizz wrote:
| If they have specific libraries or APIs that they wanted to
| deprecate, I think developers would understand that. But the
| current implementation of "anything 2 years old is too old" is
| arbitrary.
|
| If this was really about deprecation, they wouldn't have a
| "minimum monthly downloads" exemption either. This policy is
| just a way to clear out old, unpopular apps from the store
| shadowgovt wrote:
| Traditionally, this is a significant philosophical difference
| between Apple and Microsoft that goes quite a ways towards
| explaining how Microsoft gained and held dominance for so
| long in the business sector.
|
| Businesses don't _want_ to be told that their working
| software needs to be updated to make a vendor 's bottom-line
| cheaper. They recognize cost-shifting when they see it and
| respond by backing towards the exits. Microsoft maintained a
| philosophy for decades that it was their responsibility to,
| if at all possible, maintain backwards compatibility with
| older Windows software as a market differentiator. The
| primary times I remember them breaking this policy were
| security related.
|
| (That having been said, I got out of active development of
| Windows software around Windows 8, so this may have changed).
| skrtskrt wrote:
| it seems like that on a long enough timeline however,
| promising that legacy cruft will always keep crufting as it
| did before seems like a huge burden that leaks into your
| ability to deliver quality in your current offerings.
|
| Sure there are old things that are good and "complete" but
| far more old stuff is just old and could well be burnt to
| the ground, except for the fact that you have some customer
| somewhere relying on its oddities and unintended behaviors
| as an essential feature of their integrations.
| dahfizz wrote:
| Again, I don't think people would have as much of an issue
| if it was clearly about deprecation.
|
| Something like Google's minimum sdk version is annoying,
| but understandable. It's technical and concrete - you must
| link against version X because version X-1 is going to
| disappear.
|
| This is not that. It's culling apps that are arbitrarily
| too old _and_ arbitrarily not popular enough. They must be
| keeping around old sdk versions if those old but popular
| apps are allowed to continue on.
| tomxor wrote:
| > This policy is just a way to clear out old, unpopular apps
| from the store
|
| Except popularity doesn't correlate with utility when it
| comes to apps. Probably only addictive games and social
| network apps will pass whatever arbitrary threshold has been
| set.
|
| This will harm any one off apps built to satisfy a niche
| purpose downloaded by a small set of users. Which Apple
| probably think are not important, like all of the little high
| street shops, except cumulatively they might affect a
| majority of users. Also if it's measured by "downloads"
| rather than "installed", then it could take out larger more
| widely used apps that are considered complete by both authors
| and users, but don't have enough daily new users to pop up on
| their radar as important enough... this is similar to the
| "maintenance" fallacy of NPM, where frequent patches =
| better, even though if your package is small and well written
| you should be making _no patches_ as a sign of quality.
| bsuvc wrote:
| This is a great point, but if true, Apple should do a better
| job of communicating the reason, including specifics, not just
| say "your app is rejected because it is outdated".
| lapcat wrote:
| > I suspect the minimum download threshold to be exempt from
| this is _very_ high.
|
| You can suspect based on no evidence, but nobody knows, and
| Apple refuses to say.
|
| The crazy thing is, if Apple truly wants to drop support for
| older version of the SDKs, then how in the world does it make
| sense to exempt the most used apps???
| dheera wrote:
| I've had a few apps on the Google Play Store automatically
| removed because I didn't update them for some new policy or
| some such.
|
| If they paid me maybe I would have. Otherwise I don't have time
| to keep dealing with their requests every 6 months. Is it such
| a hard thing to ask that if shit works, just leave it be?
| [deleted]
| throwaway292939 wrote:
| I agree that this may be the point. Software changes, and being
| able to compile with latest libraries is somewhat of a minimum
| requirement.
|
| To Apple's defense, are they supposed to wait until the app
| breaks, starts receiving many complaints from customers, before
| it triggers the review process for them (which they would be
| forced to look at as somewhat high priority) before they then
| take action to remove the offending app? That hurts the
| customer experience from their perspective.
|
| Better for them to institute a policy preemptively addressing
| these issues (arbitrary as the timeframe may be).
|
| And four hours is a good chunk of time, but what percent of
| time is it compared to the amount of time for the app to be
| designed and implemented in the first place?
| lapcat wrote:
| > To Apple's defense, are they supposed to wait until the app
| breaks, starts receiving many complaints from customers
|
| Except that Apple is exempting apps with more downloads, and
| only punishing apps with fewer downloads, which is the
| opposite of worrying about "many complaints".
| mattgreenrocks wrote:
| I am convinced the world doesn't understand the concept of
| something being "complete." It's like part of their brain can't
| comprehend that something is functionally whole, and any changes
| would actually detract from what is there.
|
| Related: open source devs fret if a library hasn't been updated
| in the last month, even if it is feature complete with no bugs.
| electroly wrote:
| For open source code, I think the concern is practical: bit rot
| is real, and libraries with no recent updates are more likely
| to have suffered bit rot. It's not that a library can't be
| finished, but that the world in which it lives never stops
| moving. It can be a bigger or smaller problem depending on the
| ecosystem. Old C89 libraries have a good chance of still
| working, because the ecosystem isn't moving so much any more.
| Old C# libraries almost definitely don't, because the ecosystem
| is moving quickly.
| forgotmypw17 wrote:
| Perhaps the solution is a monthly "NOOP" release?
| twicetwice wrote:
| maybe commit to a log indicating that the test suite has
| run correctly as of <today's date>?this assumes you have a
| useful test suite but also at least indicates that you're
| still paying attention & trying to ensure your library
| works
| forgotmypw17 wrote:
| Great idea!
| svieira wrote:
| _quid custos ipsos custodiet_ still applies. The fact
| that your test suite ran in Esolang v27.8 successfully
| doesn 't mean what you-the-consumer want it to mean if
| the last supported version of Esolang is v96.2. It just
| means someone down-stack of you is committed to backwards
| compatibility.
| travisjungroth wrote:
| That future version won't be on the supported versions
| list anyway.
| forgotmypw17 wrote:
| I think this varies by project.
|
| I personally support every version of my projects.
|
| My goal is not to minimize the effort to myself but to
| facilitate the use of my software.
| travisjungroth wrote:
| I meant the new version of Esolang, v96.2, wouldn't be
| explicitly supported by your project.
| ep103 wrote:
| I would assume a noop is automated, and the library is no
| longer maintained.
|
| If, however, I saw a statement at the top of the README
| that said:
|
| "Update as of 2 months ago: We believe this project to be
| complete. We are not adding new features at this time, but
| if you see any issues, please open a ticket, as this
| project is still under active development as needed"
|
| then I would feel very confident.
| forgotmypw17 wrote:
| Thanks, that's a good point.
| budoso wrote:
| Agreed but this definitely isn't in the interest of library
| maintainers. If they did so it'd mean they are
| acknowledging all the currently open issues and deciding to
| do nothing, which would sometimes cause backlash.
| bliteben wrote:
| I mean most projects just auto close all issues now.
| Dunno where this desire to have 0 open issues came from.
| Seems like in the past projects would mark the issue as
| unconfirmed and ignore it, now they all want to close the
| thread and not allow further comments. Almost as if
| someone is going to judge their open source project
| negatively for having open issues, which if that has ever
| happened that person is more insane than the devs
| practicing this.
| ryandrake wrote:
| Bits don't rot--vendors break things. If my code built with
| yesterday's SDK and ran on yesterday's OS, and it doesn't for
| today's, that's not some supernatural phenomenon where
| digital media rots away--let's clearly blame who's causing
| it: SDK and OS vendors making changes that break backward
| compatibility and dump the maintenance burden on developers.
| The term "bit rot" is an attempt to shift the blame away from
| those who are causing the rot in the first place.
|
| Whether or not it's good to have a moving ecosystem is
| another story, but I request we not use the term "bit rot"
| when we mean "vendors breaking compatibility."
| hwbehrens wrote:
| > _feature complete with no bugs_
|
| I suppose for simple libraries this might be possible (e.g.
| left-pad) but how would you know in general that something is
| bug-free? `units` was introduced in 1979 and is still one of
| the canonical examples used in automated program repair
| research to show that new bugs can be found even in extremely
| well-studied codebases.
|
| I think people might be:
|
| 1. Implicitly assuming that all nontrivial code has bugs, and
| 2. Using recent commits as a signal that means, "If I ran into
| a bug, there is someone who might fix it (or at least accept a
| fix PR) to take away my immediate pain.
| __turbobrew__ wrote:
| That reminds me of the overflow bug in the JDK binary search
| that was present for quite a while.
| dotancohen wrote:
| I've never used or heard of the left-pad library, but I'm
| willing to bet that I could find an RTL bug in a library with
| that name.
| sorisos wrote:
| I like that so many unix command tools (like cat, ls...) is
| rarely updated. Often comes with a man page written in 30 years
| ago. Same with a lot of C libraries.
| mey wrote:
| If a library is not updated in some capacity "recently" (coming
| from the Java land, "recent" is a different timescale than
| Javascript), then I have little confidence that a security
| issue can be resolved if discovered. Even if a library is
| complete, it may depend on libraries downstream that _do_ have
| security issues that are no longer supported, which means it
| needs to swap to newer versions, etc.
| bsaul wrote:
| About open source lib not being updated :
|
| The thing is, even if the lib is "feature complete", it's
| pretty rare to not have to update anything, since the ecosystem
| in which this lib evolves will undoubtely have changed.
| Programming language, hardware, OS, etc. everything evolves all
| the time.
| smt88 wrote:
| Security threats also evolve all the time. A library that
| hasn't been updated in months is very likely an insecure
| library.
| bromuro wrote:
| Updates may be a security threat too... didn't log4j become
| a security treat _because_ it had been updated?
| FpUser wrote:
| I use an ancient library to perform some math. It's been
| working just fine for more than 10 years without any need
| for update. Can someone explain why is it insecure and what
| updates are needed to complex algos to make them so? When
| looking at the code it is pure computation.
|
| I think what you are saying is simply FUD when taken as a
| blanket statement.
| smt88 wrote:
| > _I use an ancient library to perform some math._
|
| Anyone can cherry-pick examples to try to disprove a
| security principle. A pure, functional math library isn't
| representative of the vast, vast majority of libraries
| that are imported every day.
|
| The most-used libraries across languages are for things
| like database access, logging, package management, HTTP,
| and (de)serialization. All of those things need to be
| kept updated for security.
|
| > _Can someone explain why is it insecure and what
| updates are needed to complex algos to make them so? When
| looking at the code it is pure computation._
|
| You didn't specify the language or library.
|
| Most libraries that people import are going to be JS,
| just because of the number of JS users and the minimal
| standard library in that language. Many are also going to
| operate on user input, which means they can have
| vulnerabilities.
|
| The mathjs package in NPM, for example, has had tons of
| vulnerabilities[1].
|
| 1. https://security.snyk.io/package/npm/mathjs
| FpUser wrote:
| C++ Library, forgot the name, need to look.
|
| NPM system is security abomination I agree. But I am not
| using it. I look at things from my own perspective. If
| 90% of the world programmers are bound to NPM ecosystem
| (doubt it) it is their problem. Not mine. I do not
| "import" half of the Internet for my "hello worlds".
| x3n0ph3n3 wrote:
| Are you passing user input into it? Does it interact with
| anything on the system? Poorly sanitized inputs present a
| very serious risk for RCE vulnerabilities.
| FpUser wrote:
| As already said it is pure computational lib. It does not
| interact with anything and I use it from my code. There
| are tons of libraries like this. They work just fine, do
| not pose a security risk and have no need for update.
|
| But thanks for trying anyways.
| layer8 wrote:
| This is only true if the ecosystem doesn't care about
| compatibility, so this is just a symptom of a deeper issue.
| Say what you will about Wintel, but the long-term
| compatibility of x86 and Windows still lets me run a lot of
| win32 applications written two decades ago without issues.
| 7speter wrote:
| Theres a good chance the documentation could say things in a
| better way...
| ako wrote:
| Everything you use continuously improves. What do you use that
| has seen improved versions since you bought it?
|
| Our knowledge, our abilities, our raw materials continuously
| improve, and everything is expected to advantage of this.
| Things that don't improve, are soon outdated and fall behind.
|
| Everything continuously improves: cars, bicycles, windows,
| houses, refridgerators, tv, etc, etc.
| layer8 wrote:
| Imagine TeX becoming unavailable because Knuth didn't update it
| for three years.
| thenerdhead wrote:
| I mean a heartbeat is needed sometimes to make sure something
| is still alive and can address critical issues if they do
| happen. But I do agree that libraries and apps don't need to
| "update" to show that.
|
| Maybe some other way like "Hey, we're still here just the thing
| we're working on doesn't need an update" would suffice for most
| things.
| aposm wrote:
| By "the world" I think you mean a specific subset of people:
| investors/execs/the business side. I don't particularly believe
| that average end users or competent engineers feel that way...
| naniwaduni wrote:
| In fact, average end users infamously don't voluntarily
| update things that aren't visibly broken.
| zeroonetwothree wrote:
| I would love to see this theoretical world in which libraries
| have no bugs.
|
| Thing is, even if there are no _known_ bugs, having rare
| updates means if I do find a new bug it's less likely to get
| addressed quickly.
| Lutger wrote:
| One word: security updates. Ok that was two. Most software had
| dependencies, those tend to surface vulnerabilities over time.
| musicale wrote:
| Other game platforms (game consoles, Windows) seem to have
| drastically better backward compatibility and API stability.
|
| If you look at the Nintendo DS/3DS (for example), the platform
| had many hardware revisions (about every other year) and dozens
| of firmware revisions, yet games from 2004 still worked on a
| brand new 3DS in 2020.
|
| On the Sony side, PS4 games from 2013 still work fine on a PS5
| in 2022 (and probably through 2029.)
|
| Steam has tons of old games that work great on Windows (but the
| Mac side took a major hit with macOS Catalina's 32-bit
| apocalypse.)
| donatj wrote:
| A PHP library I use and used to help maintain had a bit of a
| fight break out in the Issues on GitHub a couple weeks ago.
|
| They were dropping support for older versions of PHP despite
| getting nothing from it and using none of the newer features.
| Just needlessly limiting the audience, and churn for churns
| sake.
| shagie wrote:
| I am reminded of the libressl - 30 days in report.
| https://youtu.be/oM6S7FEUfkU?t=1073
|
| Removing support for old versions is a simplification of what
| needs to be considered. It is a reduction of complexity. If
| someone is running a PHP version that has been EOLed, it is
| perfectly reasonable to discontinue support for it in a
| library - even if new features that weren't available in the
| EOL'ed version haven't been added yet.
| unity1001 wrote:
| > If someone is running a PHP version that has been EOLed,
| it is perfectly reasonable to discontinue support for it in
| a library
|
| Its not. Large Linux distributions support those PHP
| versions for a long time in their LTS releases, and
| majority of web hosts and infra providers use those distros
| in their infra.
| shagie wrote:
| So what version of PHP are we talking about?
| https://www.php.net/supported-versions.php and
| https://www.php.net/eol.php
|
| That some provider is still hosting old EOL'ed and no
| longer supported versions shouldn't prevent a library
| author from saying "I'm not going to deal with something
| that had its last release nearly 4 years ago."
| taftster wrote:
| I hear you and I get what you're saying. However, to argue
| the other side, maybe it's a decision based on the
| possibility of long maintenance going forward. Keeping track
| of, in your example, PHP and all of its various versions is
| mentally daunting. What's wrong with a project just saying,
| "Hey look, we're not saying it won't work for you, but if
| you're running these older versions, we just don't give you
| any guarantees that it does. YMMV."
|
| e.g. say a bug comes up in the library, and say that it only
| affects older versions of PHP. Why can't the project just
| shrug its shoulders and be truthful that it doesn't have
| interest in maintenance/support against those old versions?
| It's better that the project declares this intention now,
| before the bug comes up, then later having to part ways with
| the old versions more abruptly.
|
| This is why OSS is great, as you can decide if, at the time
| said bug is found, that you want to provide legacy support
| for older PHP versions, maybe through a fork or other means.
| Have at it, it's your software too.
| sodapopcan wrote:
| The Elixir ecosystem is quite good for this. I've found smaller
| libraries that haven't been update in a long time but still
| work just fine since Elixir itself hardly ever changes in a
| breaking way (the recurring phrase in the community being:
| "There will probably never be a version 2"). It's weird to get
| used to at first but it's actually quite refreshing.
| OkayPhysicist wrote:
| I used an Erlang library in my Elixir project a while back
| that hadn't had an update in a decade. If a language's
| semantics don't change (and they really, really shouldn't
| change without either A) a very good reason or B) a really,
| really good backwards compatibility story) then there's
| really no reason for a library that does a job well to ever
| update.
| jeffalyanak wrote:
| I think there's something to be said about this in regards to
| consumer electronics as well. One of the oldest electronic
| devices that I still use on a daily basis is my ereader, which is
| a very early model. It simply does everything it needs to do,
| it's feature-complete.
|
| Unfortunately there aren't many consumer electronics that fall
| into that category and a huge portion of consumer electronics
| that end up in the dump are not physically damaged in any way,
| but simply can't run the latest software, firmware, or OS. Or
| else they're missing the latest wifi or cellular radios, high end
| cameras, wireless charging protocols, etc.
| SilasX wrote:
| Similar thoughts about my PlayStation 2 from 2004[0] that I
| still play Dance Dance Revolution on. I don't have to worry
| about anything changing that breaks the experience. (Except
| finding a TV that minimizes upscale lag but that should have
| been a trivial thing for TV makers to get right.)
|
| [0] The PS2 platform is from 2000 but I use a miniaturized PS2
| slim which was released and probably manufactured in 2004.
| logicalmonster wrote:
| I would advocate for Apple and other app marketplaces to adopt
| the carrot and not the stick.
|
| Incentive App developers who make good and substantial updates,
| whether its new features or updating to newer system APIs, with a
| positive % modifier to their search results in the App store.
|
| This way well-maintained Apps should show up higher in search
| rankings and there's a natural incentive for developers to keep
| their programs maintained. But at the same time, this would allow
| developers to call a program "finished" and leave it on the store
| without being scared of having their hard-work destroyed. Their
| hard-work might not be as visible, but that would be on them.
| musicale wrote:
| I don't think culling games/apps based on age is the right
| approach to improving discoverability.
|
| I don't see Nintendo removing old Switch games from the eShop.
|
| I don't see Apple Music removing the Beatles because they haven't
| updated recently.
|
| My recommendation, which Apple's (obnoxious) ad business would
| never accept, would be to
|
| 1. Remove the obnoxious and generally useless ads which eat up
| the top half of the first page of app search on the iPhone.
|
| 2. Improve app search with more options and a fast, responsive
| UI. Also they might consider allowing you to consider ratings
| from other sources such as critical reviews vs. user reviews (a
| la metacritic.)
|
| 3. Better human curation with more categories. This is the same
| approach that Apple Music takes and it seems to work well. Games
| should have Artist/Studio/Developer pages as well as Essentials
| lists to facilitate discovery. Same with genre/category
| essentials, which have a rotating list that can be
| saved/bookmarked.
| scarface74 wrote:
| APIs change, hardware changes, the comparison is relatively
| silly.
| meltedcapacitor wrote:
| Rectangle with capacitive screen is just that. Well designed
| apps should be robust to improved screen resolution, faster
| processors or network connectivity.
| Gigachad wrote:
| Older apps don't properly fit with the curved corners and
| notch.
| kps wrote:
| The 2022 SE3 has the same 750x1334 rectangle as the 2014
| iPhone 6.
| Gigachad wrote:
| The 2018 iPhone X does not.
| newtritious wrote:
| > Rectangle with capacitive screen is just that.
|
| If you think that's all a smartphone is, then it's natural
| to come to the conclusion that the only thing that has
| changed is speed and resolution.
|
| It also happens to be simply wrong.
| scarface74 wrote:
| Back in the iPhone 4/iPad era, there was no facility within
| iOS to have responsive screens.
|
| Apple introduced size classes and then you needed to adjust
| for different views for iPads once they supported more than
| one app being displayed on the screen.
|
| Apple rightfully got rid of 3/ bit app support on the
| actual die. It introduced new permission models, design
| aesthetics change, new accessibility options are added,
| better APIS are written, etc.
| II2II wrote:
| The missing point is that they are culling apps based upon age
| _and downloads_. I think this is a reasonable criteria if Apple
| is trying to make space for popular and potentially upcoming
| apps. Yes, space is an issue if you think of it in terms of the
| customer 's attention span.
|
| The real problem is that developers have no choice except to
| offer their app through Apple's store. There is no room for the
| developer to offer their labour of love or niche product in a
| storefront that better serves their needs, or even from their
| own website.
| gernb wrote:
| > Yes, space is an issue if you think of it in terms of the
| customer's attention span.
|
| By that argument they should also get rid of most old music,
| old books, old movies.
| musicale wrote:
| > The real problem is that developers have no choice except
| to offer their app through Apple's store
|
| How is this different from other walled garden game
| systems/game stores like Nintendo's eShop?
|
| Yet they seem to keep older games and apps, even niche titles
| for a limited audience (such as music production apps or
| BASIC programming apps) which I greatly appreciate.
|
| I would agree that discoverability isn't great on the eShop,
| but there are dozens of enthusiast web sites which are pretty
| good for game discovery (also aggregators like metacritic.)
|
| And, as I noted, I think Apple already has a good approach
| which they're using with Apple Music - better human curation
| including category/genre/time period/artist/etc. playlists.
| Podcasts/radio shows also help.
|
| Many games (at least ones that aren't in the "live service"
| category) are more akin to movies, music, or books than to
| some sort of perishable produce, so a curation approach that
| balances older content with new content makes sense.
| dahfizz wrote:
| It depends on how you view your phone. Is it a single use
| appliance? Or is it a general use computer?
| II2II wrote:
| Consoles are different because they have a limited shelf
| life. For example, I dug out my PS3 the other day and took
| a peek at their eshop. The most recent title was three
| years old. It also sounds like they're going to shut down
| the PS3 eshop, effectively ending the sale of old games
| anyhow. Something similar appears to be true for Nintendo.
| I pulled up their eshop on my 3DS and they have a message
| saying that it will be impossible to add funds to an
| account after March 20223. Presumably that means sales will
| end.
|
| As for other media, brick and mortar retailers were always
| selective about what they offered. I suspect that we will
| see something similar happen with their digital variants in
| the coming years. I also suspect that it will be sales
| numbers, not human curation, that will be the basis of
| their decisions.
| r00fus wrote:
| Virtual space only makes sense in terms of floorspace. If you
| want to access a backroom special-order item (virtually
| unlimited space here), you should be able to get it by
| searching for a specific item (or URL).
|
| Removing apps based on downloads or lack of updates is
| troubling.
| mcherm wrote:
| > Yes, space is an issue if you think of it in terms of the
| customer's attention span.
|
| I don't hear independent developers griping that Apple is
| failing to advertise their apps and bring those apps to the
| attention of iPhone users. Instead, I hear independent
| developers griping that Apple is preventing their apps from
| being run on iPhones.
|
| Therefore, I completely disagree. This is purely a matter of
| data storage space (cheap and nigh infinite), not a matter of
| limited attention.
| newtritious wrote:
| I hear the opposite of you. There are very few serious apps
| whose code Apple is preventing from being run.
|
| There are huge numbers of good apps on the store that don't
| get visibility.
| jonathankoren wrote:
| > if Apple is trying to make space for popular and
| potentially upcoming apps
|
| "Make space"? This isn't a shelf. There's always enough space
| for digital items.
| ghaff wrote:
| So do you want to sift through a bunch of apps that don't
| work on the current version of the operating system or are
| otherwise significantly dated?
|
| Even in a less wall gardened environment, I'm mostly not
| interested in running 10 year old applications unless
| they're something fairly simple that really does do
| everything required for the purpose and still runs
| reliably.
|
| In any case, as a user, I probably figure that if an app
| hasn't been updated in five years, it may or may not work
| and I'll probably at least subconsciously resent the
| store's owner a bit for clogging up the store with old
| stuff.
| trap_goes_hot wrote:
| >I'm mostly not interested in running 10 year old
| applications unless they're something fairly simple that
| really does do everything required for the purpose and
| still runs reliably.
|
| The 10 year old version of AutoCAD still runs, and you
| can use it today to do a ton of high-value CAD work.
| Thanks to Microsoft for not arbitrarily blocking it from
| running.
| ghaff wrote:
| Yes. But that's a case of having an old version of a
| program that you know still runs on a given platform.
| That's rather different from looking for a CAD program
| and deciding to take one that hasn't been updated for ten
| years for a spin.
| anothernewdude wrote:
| Apple should just have fewer apps. I don't see why developers
| should cater to their customers. They buy less and require more
| support. They are the worst segment to support.
| NavinF wrote:
| Are you serious? There's way more revenue to be made on iOS.
| A lot of Android users spend $0/yr on paid apps.
| metadat wrote:
| > A lot of Android users spend $0/yr on paid apps.
|
| As do a lot of iOS users. I think the stat you are looking
| for is that, on average, iPhone users purchase more apps.
|
| Don't fail to take into account Android's massive installed
| user base. Even if Droid users convert to paid at 1/4 the
| rate of iOS, you can make it up in sheer bulk.
| newtritious wrote:
| You're just wrong. The reason developers support iOS is that
| iOS users buy more apps.
| jaimex2 wrote:
| Another day, another Apple rant about the walled garden.
|
| They know you wont leave, they know you'll put up with it.
| jongjong wrote:
| I can relate to the frustration of the author. I wrote an open
| source library which gets downloaded 50K+ times per week. At one
| point, I hadn't updated it in several months and people started
| asking if the project is dead... In fact, it wasn't updated in a
| while because it had been working perfectly and was built in a
| forward-compatible way; that makes it more healthy and therefore
| more alive than probably 99% of libraries on the internet.
|
| The expectation that software libraries or frameworks should
| break every few months is disturbing. I think this may be due to
| the fact that many of the most popular frameworks do this. I find
| that React-based apps tend to break every few months for a range
| of reasons; often because of reliance on obscure functionality or
| bundling of binaries which aren't forward-compatible with newer
| engine versions.
| tinalumfoil wrote:
| I don't know the details of your particular library but I think
| 50k/week downloads and no problems is an outlier. In my
| experience even projects with small audiences tend to
| accumulate outstanding bug reports faster than they're fixed.
| oliveshell wrote:
| I'm sure you're right, but it sounds like it's an outlier not
| by random chance, but because it was built carefully.
|
| I think there's a useful lesson there.
| jongjong wrote:
| I can confirm that this is the norm for all my open source
| projects. Forward-compatibility issues can be easily
| avoided by not using too many dependencies and by carefully
| checking dependencies before using them.
|
| I check for things like over-engineering and I check out
| the author (check their other libraries if there are any).
| jongjong wrote:
| It's an open source pub/sub and RPC server/client (similar to
| gRPC) - It has a client and server component written with
| JavaScript and Node.js. I avoided using any dependency which
| relied on pre-built binaries. Also, I skim-read the code of
| all dependencies and made sure that they were well written
| and didn't use too many sub-dependencies. The trick is to
| minimize the number of dependencies and maximize their
| quality.
| api wrote:
| The use of recency as a proxy for quality or usefulness is one of
| the more perverse trends of recent years, but it's
| understandable. There is just _so much_ of everything that a
| strong demand is created for any method of filtering.
|
| Of course I have to add that it does matter a lot for certain
| types of software. Anything that interacts with ever-changing
| APIs, hardware specs, and protocols needs to be kept up at least
| frequently enough to stay useful.
| colonwqbang wrote:
| "Planned obsolesence" as a matter of official policy. Any
| cultural expression older than a few years is not worth the bits
| encoding it. Meanwhile, GTA V from 2013 is still one of the top
| selling games on Steam.
| crazygringo wrote:
| GTA V has been updated countless times since 2013, including
| entire re-releases for two newer console generations.
| colonwqbang wrote:
| The Windows port being sold at Steam is from 2015. But of
| course you have a point; there have been updates in the
| meantime. It's conceivable that those updates are what's
| keeping the game marketable.
|
| Still, I don't think Steam would confess to deleting a game
| just because it is old. They carry a lot of games which
| haven't been updated in years and which still sell.
| notriddle wrote:
| https://wiki.winehq.org/Cygwin_and_More
| bsdetector wrote:
| > My old code simply did not work anymore with the latest
| versions of Xcode.
|
| In other words if there was some actual reason to do an update,
| like a security flaw or serious bug, she wouldn't have been able
| to readily do so.
|
| This seems to support Apple's policy to make developers update
| the app every once in a while.
| lapcat wrote:
| > In other words if there was some actual reason to do an
| update, like a security flaw or serious bug, she wouldn't have
| been able to readily do so.
|
| (1) There wasn't.
|
| (2) "After 4 hours of work to re-compile my app and 44 hours
| waiting in the review queue"
|
| The biggest obstacle here isn't the developer, it's Apple.
| layer8 wrote:
| Apple is causing this issue in the first place by breaking
| compatibility and requiring projects to be updated for each new
| Xcode version.
| newtritious wrote:
| That's because the platform is actually changing.
| layer8 wrote:
| That's not a reason, unless the platform is changing in
| incompatible ways, which is exactly the problem, and a
| largely avoidable one, as other platforms demonstrate.
| newtritious wrote:
| Other platforms don't care if applications fingerprint
| the device without the user's consent.
|
| Closing off APIs that facilitate fingerprinting is just
| one of many incompatible changes Apple has been making.
|
| Some other reasons are deprecating power hungry
| technologies and asking for more permissions to access
| private data.
|
| These are changes that benefit users on a massive scale.
| Why shouldn't a developer be expected to respect users
| needs?
| layer8 wrote:
| There are ways to still maintain API compatibility in
| that case (Windows does it all the time), and it's also
| not a reason to require projects not affected by those
| changes to recompile with the newest Xcode version each
| year. I'm maintaining a Swift library/framework that
| doesn't use any iOS APIs at all, only basic Swift
| standard library calls, and I still have to produce a new
| build each year from unchanged source code so that the
| library can be consumed with the new Xcode version.
| That's just insane.
| newtritious wrote:
| Why is it insane? Do you not test your library with new
| versions of the OS?
|
| Also - "windows does it" is obviously irrelevant when we
| are talking about a mobile OS.
| RedShift1 wrote:
| The whole point of an OS is to provide a stable API to
| use.
| layer8 wrote:
| Testing with a new OS version shouldn't (and usually
| doesn't) require rebuilding the project. The need to
| rebuild is imposed primarily by the Xcode releases here,
| not by the OS. And that seems entirely unnecessary. Note
| that breaking compatibility and having to rebuild for new
| Xcode versions are two independent and orthogonal issues
| here.
|
| I won't continue this discussion about maintaining
| compatibility. This is fundamentally a philosophical
| issue. I agree with the sibling comment that it is the
| job of an OS to provide stable APIs across versions. It
| requires some effort (as a long-term library maintainer,
| I'm very well aware of this), but it is not an
| impossibility at all.
___________________________________________________________________
(page generated 2022-09-26 23:00 UTC)