[HN Gopher] Apple says they're removing my game because it's mor...
___________________________________________________________________
Apple says they're removing my game because it's more than 2 years
old
Author : keleftheriou
Score : 354 points
Date : 2022-04-23 16:55 UTC (6 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| amelius wrote:
| There is one thing worse than government regulation: having your
| market regulated by a company.
| keleftheriou wrote:
| Meanwhile, some of Apple's own apps haven't been updated for much
| longer than that - example: https://apps.apple.com/us/app/itunes-
| movie-trailers/id471966...
|
| Rules for thee, but not for me!
| lom wrote:
| App not available for me
| lupire wrote:
| I see the data feed is stale, but how do you know the build is
| stale?
| ImprobableTruth wrote:
| The version history mentions the last update.
|
| >1.4.4 Nov 3, 2017
| [deleted]
| capableweb wrote:
| It's almost like actively creating and running a market while
| also participating in it makes you gain unfair advantage. Who
| would have thought?
| giveupitscrazy wrote:
| A company could be perfectly capable of running a market
| without taking an unfair advantage on their own products.
| Apple is using terrible business practices here.
|
| Valve as an example runs steam with their own games, and also
| with paid community created remakes of their games sold on
| their same platform, they exemplify what I would expect from
| Apple, epic, Google, etc.
| mentos wrote:
| For my friends, everything. For my enemies, the law!
| tessierashpool wrote:
| gentle wrote:
| This is exactly why I refuse to buy any ios apple that cost more
| than $1. They're inevitably going away.
|
| This is also why the iPad is never going to replace a computer
| for me. Any productivity ecosystem I create for myself is just
| going to break after a couple of OS updates.
| nyuszika7h wrote:
| Generally, even if an app gets removed from the App Store, you
| can still redownload it anytime if you've previously purchased
| it. The only exception is egregious cases where the developer's
| account gets terminated. But even then, if you backed up the
| app's IPA in advance, you can reinstall it anytime. (This is
| distinct from sideloading, as an Apple-signed IPA is encrypted
| and tied to your Apple ID but has no expiry date.)
| phonebucket wrote:
| But what's the rationale behind this specific $1 limit? If
| something were to keep me entertained for several hours with no
| advertising, I'd certainly consider that worth $1. Going down
| the free route would likely end me drowning in a sea of
| advertisements.
| keleftheriou wrote:
| Similar to the author of the tweet, Apple removed a working
| version of my FlickType Keyboard that catered specifically to the
| visually impaired community, just because I hadn't updated it in
| 2 years.
|
| Meanwhile, games like Pocket God have not been updated for 7
| years now: https://apps.apple.com/us/app/pocket-god/id301387274
| ceejayoz wrote:
| Can you just add a Marshawn Lynch-style "I'm just here so I
| don't get fined" line of text to the app's "about" page and
| call it a day? Or are you gonna have to make major changes to
| update to the latest versions of iOS?
| keleftheriou wrote:
| Having to use the latest Xcode to build and submit the app is
| often already a big enough headache, due to how many things
| Apple changes between versions.
|
| Another example from someone else:
|
| "That literally happened to us. Boss wants to change our iOS
| game icon. Changing icon requires a new build. A new build
| requires iPhone X support. iPhone X build target requires
| Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old
| Unity3D. Upgrading Unity breaks build."
|
| https://twitter.com/aaefiikmnnnr/status/931222777301835782
| golergka wrote:
| That's not really about Apple but about Unity. I've
| recently written about what a nightmare it was to be a
| Unity developer:
| https://news.ycombinator.com/item?id=31065208
| mlyle wrote:
| Unity sucks, but:
|
| > "That literally happened to us. Boss wants to change
| our iOS game icon. Changing icon requires a new build. A
| new build requires iPhone X support. iPhone X build
| target requires Xcode 9. Xcode 9 requires macOS 10.12. OS
| update breaks old Unity3D. Upgrading Unity breaks build."
|
| * Apple requires you add support to new devices to push a
| new build. (this is the principal policy decision).
|
| * This new support requires you build with new tools
| (Xcode 9)
|
| * New tools require newer MacOS.
|
| * Newer MacOS doesn't compile old Unity3D code.
|
| * New Unity doesn't work with their codebase.
|
| #1 is a policy decision, and solely Apple's choice. #2,
| #3 are (reasonable) technical pain owned by Apple's
| ecosystem. #4 is an annoyance that's mostly Apple's fault
| but is shared somewhat by Unity. #5 is "Unity's fault"
| for imperfect backward compatibility.
| iamtedd wrote:
| I'm not familiar with iOS devices, but..
|
| > * Apple requires you add support to new devices to push
| a new build. (this is the principal policy decision).
|
| Doesn't the original, old app run unmodified on new
| devices anyway?
| mlyle wrote:
| > Doesn't the original, old app run unmodified on new
| devices anyway?
|
| Only in an ugly fashion because of different aspect ratio
| & notch.
|
| Apple required you to at least nominally support the
| iPhone X to push a new update to an app.
| 88913527 wrote:
| This line of explanation is an excellent example of when
| C-suite types walk in and ask, "Why can't you do {simple
| thing X}"?
| qwertycrackers wrote:
| This is of Apple madness has been my life for 6mo now. I've
| become the "deal with Xcode BS" guy for our cross-platform
| React Native app. It doesn't bother me but Apple really
| does create a lot of unnecessary pain.
| thatjoeoverthr wrote:
| I remember this sort of madness constantly. At that time,
| the Unity to iOS build process involved exporting projects
| to Xcode including C OpenGL code, which I would sometimes
| have to fix as it their compatibility would drift.
|
| Even currently I don't allow Visual Studio Mac to update
| after I learned the hard way that the new version needs new
| Xcode, which needs new macOS which isn't even available on
| my computer.
|
| (I only recovered a working setup using Time Machine.)
| willis936 wrote:
| Reading this increased my heart rate.
| viro wrote:
| > A new build requires iPhone X support.
|
| That sounds like a valid reason to require you to submit a
| new build. it came out in 2017 and most iPhones follow that
| build style now.
| superjan wrote:
| When Apple launches a new phone, they manage to keep
| "old" apps compatible with the new hardware/OS. After
| that, developers are no longer allowed to upload such
| apps, even though they would work perfectly fine. It
| would not be a big harm for apple or end users if
| developers were allowed to lag behind for a year or two.
| nvrspyx wrote:
| Just to clarify, the tweet was a couple of months after
| the iPhone X came out.
| dwighttk wrote:
| This tweet seems to be dated yesterday (4/22/22)
| mlyle wrote:
| The tweet is dated they're talking about/ linked up the
| thread, is dated: 10:09 AM * Nov 16, 2017
|
| https://twitter.com/aaefiikmnnnr/status/93122277730183578
| 2
| altairprime wrote:
| Was the removed FlickType app uploaded to the store 2 years ago
| with Bitcode on, or off?
| keleftheriou wrote:
| I can't remember. Regardless, I don't see why they'd remove
| some apps (that still work fine!) and not others, eg the
| Pocket God example I gave above which hasn't been updated in
| 7 years.
|
| Also, "unlisting" such apps would be better than removing
| them entirely, particularly since we have no alternative way
| of distribution.
| altairprime wrote:
| I have a working theory that if Pocket God was uploaded
| with Bitcode, then Apple can recompile/relink it
| automatically for each year's platform updates; and for
| projects not uploaded with Bitcode, the harsher standard is
| being applied to get that recompilation.
| dwaite wrote:
| I believe the notice said that they would be delisted
| keleftheriou wrote:
| Nope, "removed from Sale".
|
| You might be thinking about the fact that users who have
| previously downloaded the app will still be able to do
| so.
| jagged-chisel wrote:
| "Delisted" and "removed from sale" sound like synonyms to
| me. How do they differ? Neither necessary means "totally
| removed from Apple servers."
| nyuszika7h wrote:
| If an app is unlisted it could still be accessible by a
| direct link.
| bricemo wrote:
| As a game developer I've always been saddened by the ephemeral
| nature of games. It seems impossible to make a game that would
| last 20, 50, 100 years. Books, paintings, even movies have such
| an advantage
| fsflover wrote:
| It is possible. Just1 make a free software game. The community
| will support it forever if there is any interest.
|
| 1 I know, it may harm your profit, but...
| refactor_master wrote:
| That's not strictly true. There are multiple examples of e.g.
| Sony and Nintendo re-re-re-releasing old games that are easily
| 20 years old.
|
| But the comparison isn't entirely fair. If you were to compare
| a game to a concert or a festival, as an "ephemeral cultural
| performance by a large group of people" you could also argue
| that a festival lasts for a set number of days, until it's
| gone, forever.
| productceo wrote:
| Expecting to be an unpopular opinion, but this also seems like an
| effective way to enforce maintenance and progress.
|
| If a good app is no longer maintained, this will release space
| for new enterprising developers to come in and fill.
| kazinator wrote:
| If you want to make stuff for the people who chose to impose the
| Apple platform between you and them, that's what you deal with.
| It's a choice.
|
| Maybe the breaking churn in Apple is what brings the novelty
| seekers, and their money.
|
| Unity and whatever breaking and not running well on older
| hardware has to do with people buying new hardware. Those are the
| people who bring the money to the table, which is what you must
| want a piece of if you have your neck in that toilet bowl.
| butz wrote:
| Is there any effort going into iOS game preservation? Or current
| mobile games are just not worth it?
| pjmlp wrote:
| On the other side the grass has the same colour.
|
| https://android-developers.googleblog.com/2022/04/expanding-...
|
| It sucks, but this is what happens when platform vendors don't
| want to play the Microsoft's card of backwards compatibility to
| keep old applications going.
|
| Also a way to force adoption of new APIs, even if they are
| irrelevant for many applications.
| noobermin wrote:
| At this point, I see no other option other than lobbying your
| congressmembers to regulate SV companies finally. Now companies
| are enforcing the uptake of new APIs for no real purpose? Half
| of the churn is just to pad googler pedigree and advance within
| the company, it is a shame they are enforcing that culture on
| their users.
| grishka wrote:
| Except the use of Google Play is not a requirement. You can do
| your own distribution on your own terms and act as if Google
| doesn't exist.
| realusername wrote:
| Kind of but it's not a practical option, Google made it as
| painful as possible
| pjmlp wrote:
| Only if you don't care about making money with apps.
| mdoms wrote:
| In principle yes, in practice Google makes it much too
| difficult and scary for typical users.
| grishka wrote:
| It literally takes three taps to allow apps from an
| "unknown source".
| pjmlp wrote:
| No regular consumer bothers with that.
| mdoms wrote:
| With multiple big scary warnings.
| grumpyprole wrote:
| Yes, anything written for these platforms is not likely to be
| around in the same form for the long term. It's disposable
| software.
| xwdv wrote:
| > _I 'm sitting here on a Friday night, working myself to to bone
| after my day job, trying my best to scrape a living from my indie
| games, trying to keep up with Apple, Google, Unity, Xcode, MacOS
| changes that happen so fast my head spins while performing worse
| on older devices._
|
| I can't help but shake my head when Indie game devs unload these
| sob stories trying to garner support. If it's so hard for you
| then just stop making games.
|
| I often get this whiff of entitlement from indies that we should
| be supporting them because they are small, often one man
| operations. Or that because they invested so much time and money
| building a game, they should deserve to get that back through
| sales.
|
| But the world doesn't need more indie game devs, the world needs
| _better games_. I doubt a game that hasn't been updated in 2
| years is any good or doesn't have a million competitor clones by
| now.
| ratww wrote:
| _> I doubt a game that hasn't been updated in 2 years is any
| good or doesn't have a million competitor clones by now._
|
| That statement doesn't make any sense whatsoever. Games can be
| "finished products". Do you also think that movies and songs
| that haven't been updated aren't good?
|
| There are plenty of games from the 80s, 90s, 2000s that are
| still selling today, in unmodified form, running via emulators.
|
| And clones are 99.9% pure garbage that don't replace the real
| thing.
| almostdigital wrote:
| I think it has to do with swift runtime deprecations.
|
| I have an objective-c app that is as old as the AppStore and I
| haven't updated it for 8 years [1], Apple even updated it once
| themselves somehow to support iOS 11.
|
| Another of my apps was removed with a similar vague explanation
| as the OP got and it was written using Swift [2].
|
| While I understand that they might want to drop support for old
| runtimes the 30-day deadline is ridiculous. And if you miss it
| you need to re-submit the app and lose your ratings etc.
|
| I made nowhere near enough in the ~2 year period my app was
| available to justify spending the effort to modernize the project
| so I just let them remove it...
|
| [1]: https://apps.apple.com/us/app/seismometer/id288966259 [2]:
| https://github.com/jnordberg/triggy
| butz wrote:
| Could it be easier just to rewrite this game on web technologies
| and build a hybrid app for App Store? As a bonus it will work as
| PWA on any device (if author wishes to publish is like that), and
| future updates will be much easier.
| fsflover wrote:
| https://news.ycombinator.com/item?id=31135278
| jabthedang wrote:
| kbd wrote:
| What. I still play Super Hexagon occasionally and I've had that
| game on my phone for like 10 years.
|
| Checked, was last updated in 2018:
| https://apps.apple.com/us/app/super-hexagon/id549027629
| exabrial wrote:
| Good luck explaining to a silicon valley hipster why having the
| absolute latest / greatest isn't necessary.
| [deleted]
| sorry_outta_gas wrote:
| live by the store, die by the store
| userbinator wrote:
| I have binaries from early 90s (small utilities) that I wrote
| back then and still use today, and they do not need changed
| because they are truly done and bug-free. Thank Microsoft and IBM
| (PC) for backwards compatibility, it's a good thing I made the
| choice back then to stay away from Apple. Fuck forced obolescence
| and this idiotic notion that constant change is somehow
| necessary. It's only necessary to feed out-of-control corporate
| greed.
|
| If Apple had its way with everything, we'd probably all have to
| buy new appliances and rewire/rebuild our houses every few years
| because nothing would be compatible with anything older. Do not
| want.
| DaveSapien wrote:
| This has happened to me also (indie game dev) a few years ago.
|
| The number is about 20 or so games that have been removed by
| Apple because they hadn't been updated in two years. The worked
| perfectly fine on all the new hardware/software and even work
| today.
|
| On top of that, I know that there is another 30 or so apps I was
| involved in with clients that have also been removed.
|
| These weren't the biggest apps/games in the world, but they were
| all high quality finished products that had nothing wrong with
| them. Its just the cost of re-publishing each one out-weighed the
| return, so I didn't have much of a choice sadly. I do have plans
| to re-publish some of them, however they have to take a back seat
| for current work.
|
| All that to say, I have a large part of my portfolio of work that
| is no longer available to the public, which just sucks.
| septillianator wrote:
| Seems like there is justification in Seperating them into an
| archive appstore/section at least.
| macinjosh wrote:
| How closely does Apple monitor for changes? Could you simply
| update the copyright text each year and push an "update" to
| remain on the store. I can't imagine they have people looking
| at each app for new levels or features.
| meibo wrote:
| You need to recompile/submit with the newest xcode, which is
| not feasible for games as that would mean having to upgrade
| the engine.
| DaveSapien wrote:
| You are spot on, but that might even be the best case
| scenario. Thing can quickly turn south and cost quite a bit
| of time.
| AlchemistCamp wrote:
| What does it cost to republish them?
| ronyeh wrote:
| Time.
|
| For a solo / indie shop, you have limited time.
|
| Every time macOS/Xcode/iOS updates, some of the iOS APIs are
| deprecated in favor of "the new better way of doing things".
| You have to keep up, or else your old apps stop compiling at
| some point.
| jws wrote:
| Best case, check out your code, bump the version number,
| touch up your copyright date, hit "Run", do your testing1,
| hit upload, have a sandwich, check it out in TestFlight,
| approve a release, maybe check a few boxes that say you
| aren't shipping super secret encryption technology to shunned
| nations.2
|
| But usually after a few years Xcode will bitch at you about a
| lot of stuff, so maybe you raise the minimum OS version
| requirement, click "Fix it" on a lot of API respellings, find
| a couple that it can't automatically fix so you have to
| google that a bit. Then test and upload.
|
| Maybe get in a fight with Xcode over your signing keys.
|
| Sometimes something you were using gets deprecated and you
| have to use the newer replacement. That takes some coding.
|
| It can get ugly if the 'owner' in the app store is not you or
| is an entity you no longer control. Then you have to get them
| involved to do the chain of trust signing.
|
| If you produced it under contract, you may not be legally
| allowed to update it without a new contract.
|
|
| 1 _do your testing_ is easy to say, but that could take an
| arbitrarily long time depending on how thorough you are. I
| expect this to be the dominant cost for most game updates.
|
| 2 I pulled out one of my aging apps and just did all this to
| check, 10 minutes from "checkout" to "installed in
| TestFlight". The dreaded App Store review was 3 minutes. This
| isn't really a fair data point though, Xcode didn't suggest
| any source code changes so it was just bumping numbers and
| rebuilding.
| DaveSapien wrote:
| If only it where only that simple.
|
| There are many dependancies that require some kind of
| reimplementation, it's a pain.
|
| I have made things easier (in the long run) with my last
| game. I wrote it all in c++ with all dependancies under my
| control. I was thinking >20 years ahead for that one.
| DaveSapien wrote:
| Zero, just my time. And the cost of fixing all the problems
| with new versions of Xcode, Unity, and whatever else was used
| and has now changed.
|
| It can become quite the rabbit hole, and thus quite costly.
| traspler wrote:
| Mostly time and hassle I would imagine. Apples requirements
| also shifted in the meantime so you might also be forced to
| provide more info/pictures/etc. which again comes down to
| time and hassle.
| DaveSapien wrote:
| Yeah, spread that over 20 games/apps. It can really mount
| up, I can think of other indie game dev's that only publish
| on iOS that their games are now forever lost.
|
| It's a real cultural loss.
| lupire wrote:
| Publishing only on proprietary OS in the first place is a
| cultural loss.
| altairprime wrote:
| Were the removed apps compiled with Bitcode enabled in Xcode?
| DaveSapien wrote:
| Some, most of them not.
| lupire wrote:
| Looks like Apple is exposing nasty bugs in Unity's failures to
| maintain compatibility with old source code.
| [deleted]
| vimy wrote:
| This happened to my sticker app. Simple iMessage stickers. The
| stickers are done and I have no desire to add more. What is there
| to update? ...
|
| I can't wait until Apple is forced to add third party stores.
| kerng wrote:
| This is very bad news for indies, and will help large companies
| push them out.
|
| I have games in AppStore not updated for many years. They work
| well on all devices, I also consider them to be a piece of art.
| And feedback is very positive!
|
| Getting anxious that Apple will pull it.
|
| Releasing a new version sounds easy, but it's a significant time
| effort (chain of dependencies, build environments and game
| engines are complex) with 0 value to anyone - because it is
| perfect and a piece of art.
|
| Why don't they have better options for discovery, rather than
| saying "old is bad".
|
| I have comments from people saying my game is their favorite
| childhood game and they have they have fond memories and stuff -
| and they are happy to play it now once in a while even.
|
| Apple logic makes zero sense, it's like destroying books or
| paintings and stuff.
| Crabber wrote:
| Calling something "art" doesn't magically make it immune to
| decay.
|
| Paintings have to be restored, books have to be reprinted.
|
| If your art is so cherished to you and other people then surely
| that should give you even more motivation to spend time
| ensuring that it is preserved into the future, no?
| infogulch wrote:
| How much is this about being 'fresh' or using new OS features vs
| running old apps through their changed policies and app
| submission screening process?
| m34 wrote:
| At some point it makes sense to update even if the content itself
| is "complete": supporting newer screen resolutions natively
| (instead of going with some kind of fallback behavior), making
| sure all the outdated and long since sunset 3rd party SDK calls
| don't cause crashes etc.
|
| Also if you managed to build, prepare (App Store metadata in
| different resolutions etc), submit and finally get your app
| shipped to the end user that was no small feat a couple of years
| ago. Probably not a very useful skillset to have if you only do
| it very infrequently (read: waste of time).
|
| Requiring additional screenshots, icon sizes, universal app
| (iPhone+iPad, also supporting split view), new copy for different
| types of meta (e.g app sub title) for all the locales you
| probably had translated externally at some point, new privacy
| guidelines etc.. all not very attractive to get into even if not
| forced to update like this, especially if you lose your ratings
| in the process.
| layer8 wrote:
| I was disappointed when I had to stop using the iSSH app because
| it wasn't ported to 64 bits, since the author had died. Now I
| guess it wouldn't have helped much if the app had already been 64
| bits. Stuff like this is why I would be in favor of alternative
| app stores.
| ianlevesque wrote:
| Or switch to Prompt, which is actively maintained by one of the
| best iOS/macOS developers out there.
| layer8 wrote:
| I have, out of necessity, but there were some features I
| liked iSSH better for.
|
| The other "important" app I lost to the 64-bit transition was
| Mr. Driller. ;)
| tedunangst wrote:
| Uh, well... I bought prompt. Version 1. Which they quickly
| discontinued and delisted. I'm not paying again for prompt 2.
| TheChaplain wrote:
| We need independent appstores where developers can distribute
| their work as they see fit.
| gameswithgo wrote:
| ianlevesque wrote:
| I am having trouble summoning the outrage I see in the other
| comment threads here. The App Store is stuffed full of
| abandonware. Apple should be more aggressive with this, not less.
| If you can't recompile your app and patch up support for recent
| OSes and recent devices on an ongoing basis, then your business
| model is not sustainable. I know, I used to sell iOS apps.
|
| The market right now is absolutely flooded with indie games, some
| light pruning is probably for the best.
| poisonborz wrote:
| Just imagine this requirement on any other operating system.
| logicalmonster wrote:
| How about using the carrot and not the stick?
|
| If you say something like "apps that are recently updated and
| using all of the latest APIs should be ranked higher within
| Apple's search algorithm and recommendations", that would make
| quite a bit of sense to me as an incentive to keep development
| and progress moving forward with all of the updated tech.
|
| But it makes no sense to force devs to expend the effort to
| recompile and update an App just for the sake of staying on a
| store if everything is already working perfectly as intended
| with no security issues. This is especially a crap deal for
| small developers without endless resources to continuously be
| working on rebuilding and retooling projects just for the sake
| of Apple's inability to do search and discovery well.
| ianlevesque wrote:
| A lot of the comments here are focusing on indie developers,
| but honestly the worst offenders are huge companies that
| aren't focused on software, like HVAC, IoT, automotive.
| They'll hire out a subcontractor _once_ to throw an app over
| the fence and let it rot. There 's no market pressure up
| front when you are buying a washing machine to evaluate the
| support model for the companion apps, so this isn't a problem
| that solves itself. Apple has now forced these companies to
| maintain their stuff, and the market will be better off for
| it.
| rtlfe wrote:
| > Apple has now forced these companies to maintain their
| stuff
|
| No it hasn't. They can rebuild without improving anything.
| noobermin wrote:
| I somehow can't believe Apple cares that much about either
| group, regardless of who in some manufactured statistical
| methodology you feel is the "worst offender." This has more
| to do with control than anything else, because I am unable
| to imagine a better fitting explanation. May be the "why"
| isn't really what you were addressing with your comment,
| but if it was, this can't be a "why."
| egoisticalgoat wrote:
| And then you have the other side, where the company doesn't
| upgrade the app (either cost savings or the company went
| under) and now you have an expensive brick because the app
| is suddenly gone from the store.
| adrianmonk wrote:
| > _But it makes no sense to force devs to expend the effort
| to recompile and update an App just for the sake of staying
| on a store if everything is already working perfectly as
| intended with no security issues._
|
| Sure, but realistically how does Apple tell perfectly fine
| apps apart from apps that are abandoned and do have security
| issues?
|
| Hand-auditing every app doesn't seem realistic. I doubt a
| good automated solution is either.
|
| They could just take developers' word for it, but Apple has a
| responsibility to protect end users. If you tell a developer,
| "your answer to our next question determines whether we
| remove your app", then you can't count on them to answer
| honestly because you gave them an enormous incentive to lie.
| kitsunesoba wrote:
| > Sure, but realistically how does Apple tell perfectly
| fine apps apart from apps that are abandoned and do have
| security issues?
|
| Not to mention, the more apps with an inch-thick layer of
| dust there are on the App Store, the more they become
| trapped in the same kind of backwards compatibility mire
| that Microsoft is now stuck in. They could just hide apps
| that don't run on newer versions of iOS I suppose, but with
| the extremely high system upgrade rate of iOS users that's
| practically the same as removing them from the store.
| lupire wrote:
| I don't know, how does Apple tell perfectly fine _new_
| apps, that don 't even have a track record of satisfied
| users (with telemetry that Apple has), from new apps that
| don't work?
|
| How is the age of the app relevant?
| Hackbraten wrote:
| Older games sell a lot worse than freshly released ones. Non-
| game apps somewhat depend on freshness too, but I'd guess not
| so heavily.
|
| That would make ongoing maintenance more expensive for games
| than for other apps. Maybe Apple should honor that and allow
| more slack for games.
| gcheong wrote:
| If they actually gave any indication of what exactly they think
| needs to be updated other than the age of the app I would tend
| to agree but if an app is considered complete and running fine
| on current devices then it's not abandonware.
| brundolf wrote:
| Games in particular usually don't use a lot of system UIs or
| other integrations (and so are less likely to break or visibly
| age), are often developed on a shoestring budget (so developers
| will have less time and resources to keep updating them over
| time), and have artistic value.
|
| Kicking them off the only store on a closed platform is erasure
| of artistic history. It's doubly insulting when they still work
| perfectly without modification.
|
| For comparison: I've never heard of a game getting kicked off
| of a console's store because of a "lack of updates". The stores
| _themselves_ usually shut down eventually - which is its own
| problem - but at least there 's a reasonable business argument
| for why the company can't be expected to offer that service
| indefinitely.
| scarface74 wrote:
| And consoles only change hardware or operating systems once
| every six or seven years.
| brundolf wrote:
| And the store usually stays online for another 3-4 years
| after the console's successor has come out
| gameswithgo wrote:
| Asooka wrote:
| Microsoft somehow manage to maintain backwards compatibility
| for much longer than two years.
| layer8 wrote:
| If people are still downloading and using an app, that should
| be reason enough to keep it. I would understand removing apps
| that virtually no one has downloaded, and also actually used,
| in the past two years. This may conceivably have even been the
| case here, but then Apple should communicate exactly that.
| com2kid wrote:
| Removing by sale / usage rate might be fair.
|
| No one opened your app in 2 years? It gets the boot.
|
| If an app is still actively being used, removing it hurts
| developers and users!
|
| I have apps on my Android phone that haven't been updated in
| years. They work just fine.
|
| Heck on my MacBook I use an app that wad last updated in 2016
| or so, and I consider it a vital pri0 part of my daily
| workflow!
| Hammershaft wrote:
| > The market right now is absolutely flooded with indie games,
| some light pruning is probably for the best.
|
| By arbitrarily removing perfectly working older games? This is
| why indie devs such as Vlambeer that used to make quality
| mobile games now avoid ios and android like the plague.
|
| https://variety.com/2019/gaming/features/android-ios-apple-g...
|
| The result of this is mobile games require significantly more
| upkeep then games on PC or consoles, and as a result the only
| games that are profitable in the long run are those that
| exploit their users with f2p microtransactions.
|
| The end result of this is the sea of uninspired exploitative
| trash that makes up the games market on ios and android.
| andai wrote:
| >Ismail said that either Apple has to start designing for
| backward compatibility support on their end or that people
| are going to have to get used to the idea of games dying and
| disappearing.
| AlexandrB wrote:
| Yes, this is exactly right. And it doesn't make sense for
| games that have no online component (like those made by
| Vlambeer) to need updating for security/privacy reasons.
| Apple consistently misses the mark on what makes a platform
| good for games and then makes empty promises about "getting
| serious about gaming".
| kitsunesoba wrote:
| As a dev myself, I agree. You can't really expect to just toss
| a binary over the wall and forget about the project for the
| next decade.
|
| Software is an ongoing commitment and periodic recompiles and
| fixes should factor into architecture and planning. Some
| decisions early on can save you a lot of pain. For instance,
| building your app with stock UI widgets to the greatest extent
| possible and limiting custom widgets and third party stuff to a
| minimum goes a LONG way for making your apps weather new OS
| versions better. These days my UIKit apps only need a handful
| of minor changes when a new OS version is released, making them
| trivial to maintain.
|
| Choosing Unity was a big part of the problem in this case
| because Unity is terrible about maintaining particular versions
| of their engines over time. Devs need to start dumping Unity
| over this, because it's the only way that Unity is ever going
| to fix it.
| howinteresting wrote:
| This is simply false. _Some_ software is an ongoing
| commitment. Other software can just be done and never need to
| be updated. An indie game with no online component falls
| squarely in the latter bucket.
| wtallis wrote:
| > You can't really expect to just toss a binary over the wall
| and forget about the project for the next decade.
|
| You can on Windows. Microsoft has shown us what a three
| decades of maintaining an OS to that standard will do to a
| platform and its software ecosystem. There are definitely
| pros and cons to taking that approach. These days, as a user
| I'd much rather have decent emulators of older platforms and
| operating systems, rather than rely on the current OS to be
| completely and forever backwards compatible. But that doesn't
| seem like a good solution for mobile platforms or their app
| stores.
| scarface74 wrote:
| And Windows also shows you what happens when you have
| layers upon layers of compatibility hacks and the security
| nightmares it brings. One of the first major IIS security
| issues happened because of the eight different string types
| and conversions between them to work with the various APIs.
|
| You could "hack" a Windows server running IIS just by
| encoding DOS commands in the URL bar.
|
| http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm
|
| Also, by Apple eventually abandoning backwards
| compatibility, it was able to migrate Macs to different
| better processors four times.
|
| By abandoning 32 bit software support, it was able to save
| space on its processors.
| kitsunesoba wrote:
| Windows really is the exception and not the rule, though.
| In fact in the free and open world of Linux, backwards
| compatibility is even worse... a binary compiled a year ago
| has a good chance of no longer working. Stuff like Flatpak
| is improving that situation a bit, but it's still nowhere
| as backwards compatible as Windows.
| nezirus wrote:
| It is actually the oposite on Linux. You compile on older
| distro (e.g. CentOS 6), and it will work on later
| versions, (CentOS 7).
|
| https://developers.redhat.com/blog/2019/08/01/how-the-
| gnu-c-...
| wila wrote:
| > In fact in the free and open world of Linux, backwards
| compatibility is even worse...
|
| I have linux binaries from 2001 that still work fine on
| recent Linux kernels.
| berkut wrote:
| If they're CLI C ones, or statically link all deps:
| sure....
|
| If they link against libstdc++, Qt or Python, good
| luck...
| kitsunesoba wrote:
| Those three you listed have definitely been the most
| problematic by far when trying to run things on Linux.
| noobermin wrote:
| An amazing sentiment calling the operating system used
| the most across the entire world and exception rather
| than a standard. And I don't know how you envoke the
| problem (yes problem) of broken dependencies on linux and
| think it adds to your argument on why this is a good move
| by Apple.
| Aulig wrote:
| iOS and Android usually have perfect backwards compatibility,
| so there's no technical reason to require a new build. The apps
| work perfectly fine on new devices automatically.
| simonbarker87 wrote:
| I received an email this morning saying the same about one of my
| apps, it hasn't got any crash reports, still gets downloads after
| 5 years, doesn't need a v2 and Apple decide it's time to go. Due
| to swift version changes I don't have time to push a meaningful
| change as it doesn't compile any more.
| TheJoeMan wrote:
| LowStakesConspiracy: Apple needs to keep developers buying newer
| Macbooks / iPhones.
| meibo wrote:
| This is/has always been obvious to everyone that works with
| Apple hardware/software, it's not really a secret.
|
| They move this fast to keep people on their toes - they know
| that everyone will just have to keep running after them,
| otherwise you lose a huge part of your userbase.
|
| I assume this isn't as much of a problem for regular apps, but
| games are finished pieces of art and recompiling them with a
| new engine version is often unfeasible.
| clintonb wrote:
| I disagree. The latest version of Xcode ran on my 2013 MBP,
| until a recent upgrade. Using the latest hardware is much
| faster, but not required.
|
| I intend to keep my new MBP for another 8-10 years.
| Veuxdo wrote:
| I'm surprised a 2013 Apple anything even turns on.
| meibo wrote:
| From what I know, older Apple hardware(<2013) is vastly
| more repairable/durable. Wouldn't be surprised if quite a
| few people are still running that.
| schwartzworld wrote:
| I have a 2012 MBP that still works just fine. Better than
| some of the newer Apple devices work has thrust upon me.
| I also have a g3 imac that turns on just fine.
| ratww wrote:
| I was using a 2011 12" MacBook Air until recently, for
| work, music making and personal usage. Only traded for an
| M1 because thought it was cool. If anything it's 3rd
| party dev stuff that requires bleeding edge machines (eg:
| Docker).
| woah wrote:
| No, actually, upgrading X Code requires a trip to Apple's
| website. On Apple's website, mobile application developers are
| likely to come across previews of great new content on Apple
| TV+, thus enticing them to sign up for Apple's streaming
| offerings.
| dagmx wrote:
| This is untrue. Xcode is available in the App Store on Mac.
| You don't go to the website to get it.
| cyral wrote:
| You can get it from either
| viro wrote:
| Or they don't want customers downloading apps that don't
| properly support their devices. makes the customer experience
| suck.
| Brian_K_White wrote:
| The customer-breaking changes are coming from Apple, not the
| app developers.
|
| If Apple is so concerned about customer experience, they can
| just as well choose not to break existing apps.
|
| The "customer experience" excuse hasn't held water in
| decades.
| Someone wrote:
| I think it has. On Windows, famous for its backwards
| compatibility, you still have software that shows ancient
| dialogs, have graphics at a resolution for 640x480
| monitors, or that work with 8.3 file names, and only with
| those (so, you can't save docs with long names, and have to
| guess at the short names of files and directories with long
| names)
|
| Yes, banning such apps is a loss for the customer
| experience of being able to run such applications, but
| there are disadvantages, too. For many of those
| applications, users would be happier _if_ those
| applications were maintained and adjusted to modern
| hardware and new OS capabilities.
|
| Now, of course, that's an _if_. Apple makes a different
| choice than Microsoft there. They think losing applications
| isn't a big problem (presumably as long as replacements
| exist, but even that isn't strictly necessary for some
| tools. The public at large can do without a Kermit program
| or RSS reader, for example, because it has alternative ways
| to download files or access news)
| etchalon wrote:
| "If Apple is so concerned about customer experience, they
| should stop making their products better." is an
| interesting take.
| Brian_K_White wrote:
| What's interesting is no one said that.
|
| Inventing your own false statement so that you can point
| out how false it is, is an utterly uninteresting
| approach.
| [deleted]
| mysterydip wrote:
| This is exactly why I wanted to leave Apple's ecosysyem for my
| games and go pure HTML5. Attention and updates (XCode, OS) needed
| just to keep an app up, not worth the time for me.
| aendruk wrote:
| I'm personally banned from selling on Amazon "due to inactivity".
|
| In college Amazon advertised on campus that you could sell your
| textbooks, so I did that. Now, years later, they advertise "Sell
| Your Stuff"--but too bad, in the interim my account was closed
| _without notice_ and there's no appeal, and no way to open a new
| one.
| nyuszika7h wrote:
| 2 years is definitely too early, especially considering they're
| doing this to developers who are continuing to pay them $99/year
| to keep their apps up. The iPhone X came out 5 years ago, that
| was about the last time an update was needed to not look bad on
| newer devices. Some other commenters here fail to understand that
| many games are simply completed and don't need much updates to
| keep working on newer devices, especially if they purposely use
| minimalistic graphics. Even for regular apps pruning them after 2
| years is a bit excessive but it's slightly more understandable
| there as they'll feel dated more quickly.
| mdoms wrote:
| Stop tending other peoples' gardens. Especially trillion dollar
| companies' ones. No sympathy here, we all know the drill by now.
| clintonb wrote:
| > Stop targeting the two largest mobile platforms to gain
| customers and revenue.
|
| That's my paraphrasing of your statements. If the customers are
| in the garden, you have to go to the garden. That's easier than
| building your own.
| amelius wrote:
| > Stop tending other peoples' gardens. Especially trillion
| dollar companies' ones.
|
| Meanwhile, Apple built their castle in TSMC's kingdom ...
| gcheong wrote:
| I will the day the US gets serious about cracking down on
| monopolies and I have several gardens to choose from or can
| start my own.
| throwaway14356 wrote:
| Its just rude to support such eco system.
|
| As an experiment i tried an iphone4. Apple support helped
| register an account which didnt work any more for multiple
| reasons, the app store works just fine, you just cant get any
| software. Clicking on download does dl the apps but then it
| says you must upgrade your OS.
|
| There is no software!
|
| Developers say they have a version for it but you may not
| install apple says. What kind of deal is that? Its a good
| device, it could have all kinds of applications.
| scarface74 wrote:
| The iPhone 4 is not a "good device". It's 3G only and the
| networks have already announced that they are completely
| shutting down 3G networks by the end of the year.
| ratww wrote:
| Sure, but it could still be used as a wifi-only device. I
| have an old iPhone 8 that I keep around for music and
| streaming to a TV.
| jobs_throwaway wrote:
| Bluecobra wrote:
| Just append "2022" to your game's name and update the copyright.
|
| I just played a "new" Pool & Snooker 2022 game in Apple Arcade
| and it looks and plays like Pool & Snooker 2012. The copyright
| says 2012-2022 so I assume the devs just lazily update the name
| each year and nothing more. Not seeing 10 years of improvement in
| this. Some of the graphics still don't even have anti-aliasing...
| ChrisMarshallNY wrote:
| I have had many apps (over 20) on the store, since 2012.
|
| I haven't had any that has weathered the OS changes past a couple
| of major steps, without having to make some code changes
| (sometimes, nothing more than just recompiling with the latest
| toolchains).
|
| I just put out an update to my very first app, which is ten years
| old, but I have done a few updates, since first releasing it.
|
| I have another app that is about two years old, and it needs a
| facelift. I don't have the bandwidth to give it said facelift (It
| still works, but looks like crap). I hope it won't get pulled
| before I can give it its update. I won't blame Apple, if they do
| pull it, however (see "looks like crap," above).
|
| I've generally retired most of my apps, when they got long in the
| tooth.
| [deleted]
| dheera wrote:
| Yeah I used to have a bunch of (mostly Android Wear) apps on the
| Google store but they started getting deleted one by one, they
| kept having new policies that you needed to follow to have your
| app stay up. I have a dayjob and don't have time for that shit.
| Pay me and I'll do it.
| w0mbat wrote:
| It's not hard to do a recompile with a slightly newer SDK, check
| things still work, update the version and copyright and re-
| upload. That's how I keep all my apps in the store. Often you
| find a cheap update you ought to make, like add dark mode support
| which wasn't a thing when the app was written. Sometimes you take
| the app across a tech boundary, like adding ARM code to a Mac
| app. I can see Apple's motivation to keep fresh goods on their
| shelves that work with current OS versions and hardware.
| TedDoesntTalk wrote:
| Some apps are feature-complete.
| newbalance wrote:
| It's hours of work - recompile, test, publish, test again once
| new versions hits the App Store. Upgrades and maintenance are a
| bigger time sink than most consider.
|
| And this assumes there aren't any new issues that need fixing
| during the maintenance.
| capableweb wrote:
| Games are immensely more complex than your average run-of-the-
| mill smartphone application. As the author of the submission
| tweet themselves say:
|
| > Now I need to dig up my project file, update the Unity
| version to make sure it meets the App Store requirements,
| rebuild, retest, resubmit all to get the exact same game in the
| exact same place it was before.
|
| From my own experience, updating the Unity version tends to not
| be hassle-free, especially if it's a major version. Updating
| xcode tends to be a hassle as well, if not outright impossible
| unless you keep buying new Apple hardware too.
|
| And why is the onus on the developers to update apps just for
| the sake of updating them? Can things not just be "done"
| anymore? There doesn't seem to be any specific reasons except
| "we like fresh updates" provided for why the updates should be
| done.
|
| If it works, why remove it? Are they running out of space? Are
| people being fooled by the application somehow?
| Gollapalli wrote:
| Updates should be required only when specific apis or
| features are deprecated and the app in question uses those.
|
| But there probably isn't an easy way to test whether an app
| uses them. Aside from literally going through the binary,
| looking for those calls or something.
| rockbruno wrote:
| Only if you're doing it constantly for every SDK update. But if
| your game is complete then you have no reason to do it, and if
| you haven't updated your SDKs in 2 years, chances are that you
| will not be able to do it without re-writing a huge part of the
| software.
| thewebcount wrote:
| I understand being upset with Apple at this arbitrary cutoff. But
| can we also talk about why a recompile isn't as simple as opening
| the old project and hitting "compile"? I work on a large project
| (millions of lines of code), which has been in continuous
| development for 20 years. Every new compiler or IDE release
| results in us having to dedicate at least one engineer full time
| for a few days to get our project compiling again with the new
| tools before the team can switch over. That's a project that
| previously compiled with no errors or warnings (because we set
| warnings are errors to true) suddenly can't build. It's
| ridiculous! I can't imagine throwing something like Unity in on
| top of that.
| cpeterso wrote:
| Someone replied to the original tweet with an example of their
| iOS dev experience:
|
| _Boss wants to change our iOS game icon. Changing icon
| requires a new build. A new build requires iPhone X support.
| iPhone X build target requires Xcode 9. Xcode 9 requires macOS
| 10.12. OS update breaks old Unity3D. Upgrading Unity breaks
| build._
|
| https://twitter.com/aaefiikmnnnr/status/931222777301835782?s...
| arinlen wrote:
| > Boss wants to change our iOS game icon. Changing icon
| requires a new build. A new build requires iPhone X support.
| iPhone X build target requires Xcode 9. Xcode 9 requires
| macOS 10.12. OS update breaks old Unity3D. Upgrading Unity
| breaks build.
|
| * The iPhone X was released on 2018.
|
| * Xcode 9.0 was released on 2017, and 9.4.1 (last release) on
| 2018.
|
| * macOS 10.12 was released on 2016.
|
| I'm sorry to say, but this sort of setup does not reflect
| well on anyone working on the project. Apple's call out
| should be considered a wakeup call.
|
| Also, doesn't Xcode 9 only support iOS releases up to iOS 11?
| The global market of all iOS versions lower than iOS 11
| should lie in the lower single digits.
| michaelt wrote:
| You do realise the tweet you're replying to is from 2017?
| maccard wrote:
| The problem here is unity (which, by the way is one of the
| most popular game engines, and is often sold as the indie
| friendly, mobile friendly engine). Standard operating
| procedure for Unity games is pick the latest LTS engine
| version as the base for your project, and don't ever
| update, because the updates are _so_ much work it's
| untenable to keep up with them. (This was official advice
| given to us by a unity sales rep at one point in the last 2
| years).
|
| These aren't like node updates, these are closer to Firefox
| removing legacy extensions, except happening quarterly.
| There's no guarantee that something that is "stable" in
| your version will work the same way in a newer version.
| Unfortunately, the engine is tied to specific iOS SDK
| versions, so in order to use a more recent iOS SDK you're
| forced to upgrade your unity version alongside it...
| TeeWEE wrote:
| It's called code-rot..
|
| Systems improve over time. Apple's privacy in iOS improved a
| lot. Not updating your apps makes it hard to keep up with API
| changes. Its normal you have todo some work to ensure it
| still works. Sometimes you're out of luck. But not all
| dependencies stay with us forever. Software is sadly enough
| not immutable, environment impacts how software runs... My
| old android game stopped working on newer devices 3 years ago
| due to a OpenGL bug that was fixed, i depended on the bug in
| order to make my app work.
|
| Welcome to the real world
| tragictrash wrote:
| While I loathe apple's moves lately, including this one, I
| have to agree with this comments sentiment.
|
| Software is not free once written. You need to expend
| resources to keep it up to date and secure.
|
| If you aren't keeping things up to date, you are neglecting
| the maintenance of your application. You wouldn't be
| surprised if your car stopped working if you never change
| the oil. Apple is taking proactive actions here, presumably
| to protect the end user experience. Wether or not I agree
| with the manner of proactive action is a different issue.
| We know apple loves to exert tons of control over things
| like this.
|
| Apple is difficult to work with. It takes maintenance to
| keep apps up to date. Yes, the two year thing seems a bit
| over the top but remember the real issue is that this guy
| can't submit a new build because he hasn't added support
| for the last two OS versions.
|
| The app store is hard to work with, but they payoff is
| immense also.
|
| Welcome to the real world.
| ordiel wrote:
| Immense - 30% they take to give you more trouble and kick
| you out whenever they deem it "necessary"... you know
| 'cuz you, their customer is the biggest threat to them
| and the users (Google/Apple)... honestly at this point I
| am all down to just go to another app store... once they
| let you do that without restrictions on the device Yyou
| paid for....
| tragictrash wrote:
| Listen, I totally agree with you. It's total BS and
| should be better.
|
| That being said, I also think your frustrated and typed
| word salad into the reply box.
|
| I'm not apple. I don't like apple's practices. I don't
| own any apple devices (beyond what's required to support
| an iOS app) because I take an issue with the same things
| you do.
|
| The reality is, if you want to support apple devices, you
| have to play their game, and that means updating your
| apps regularly. Sorry if you don't like it. I don't
| either.
|
| Again, welcome to the real world.
| msla wrote:
| Linux runs thirty-year-old binaries because of kernel and
| hardware compatibility.
| exabrial wrote:
| > Systems improve over time
|
| They do, but Apple intentionally harms older systems.
| ohgodplsno wrote:
| Meanwhile in the real world:
|
| Windows software still runs 20 years after in compatibility
| mode
| colejohnson66 wrote:
| Technical debt has a cost. Raymond Chen has countless
| blog posts about what it takes keeping backwards
| compatibility working. For example, an update to some
| part that should not break anything actually ends up
| breaking an app because the developers decided to monkey
| patch based on a match of a byte string or whatever that
| ended up changed.
|
| The only reason WINE works is because of a massive
| community effort to reimplement those bugs that Windows
| is forced to keep.
| frosted-flakes wrote:
| The binary still runs, but can you re-compile from
| source?
| ithkuil wrote:
| As long as you keep your old tool chains and old
| dependencies etc etc
| franknine wrote:
| Sometimes they just force you to implement feature for
| them, like "Sign in with Apple"
|
| > We've updated the App Store Review Guidelines to provide
| criteria for when apps are required to use Sign in with
| Apple. Starting today, new apps submitted to the App Store
| must follow these guidelines. Existing apps and app updates
| must follow them by April 2020. We've also provided new
| guidelines for using Sign in with Apple on the web and
| other platforms.
|
| > 4.8 Sign in with Apple Apps that use a third-party or
| social login service (such as Facebook Login, Google Sign-
| In, Sign in with Twitter, Sign In with LinkedIn, Login with
| Amazon, or WeChat Login) to set up or authenticate the
| user's primary account with the app must also offer Sign in
| with Apple as an equivalent option.
| bspammer wrote:
| Which is great for users. I seriously love Sign in with
| Apple because it lets you hide your email address from
| random app #941245.
|
| I always wondered why so many apps support it because it
| seems like they'd prefer to know your real email, but now
| it makes sense.
| franknine wrote:
| And implementing Sign in with Apple in Unity is one of
| the worst experience in my career that I dedicated a blog
| post talking about: - Native Sign in with
| Apple button not working in Unity - Official Sign
| in with Apple plugin provided by Unity also not working
| - Hooked up API with help from GitHub and created Sign in
| with Apple button by myself ended up getting `4.0 Design`
| rejection without explanation - Trying crazily to
| contact Apple reviewer for weeks only to find out you
| have to use system font on that button - Unity
| cannot support new Thai system font after iOS 13 and they
| mark it won't fix - Ended up building a native
| sample app and screenshot Sign in with Apple button from
| it in 12 different languages into PNGs and ask the my
| designer co-worker to remove background for me to import
| them into Unity - After all these the update is
| finally accepted by App Store - Casually downloaded
| games by other companies a week later, saw a totally
| malformed Sign in with Apple button not being nitpicked
| by reviewer and just went live like that
| heavyset_go wrote:
| I can still run 20+ year old demoscene binaries on Windows
| and WINE. Linux binaries from that period still work, as
| well.
| michaelt wrote:
| While Apple _could_ do a Microsoft and try to keep third-
| party software working for decades, they 've realised
| they can offload that work to the third parties for free.
| bagels wrote:
| Systems improve over time.
|
| They at least change over time. Not all of them improve.
| markdown wrote:
| > OS update breaks old Unity3D.
|
| I'm still on Mojave because I'd have to say bye bye to Adobe
| Fireworks if I upgraded.
| KennyBlanken wrote:
| You've had a _decade_ to find an alternative to Fireworks -
| a vector graphics program.
|
| It might be time to move on.
| andai wrote:
| I still use EasyToon, originally published 1998. Then
| again, I'm on the only operating system that actually
| values backwards compatibility.
| Robotbeat wrote:
| Imagine if the tools in your shed turned to dust after 5
| years. And these are analogue, physical objects. Digital
| objects if stored in a properly error-correcting medium,
| can last indefinitely. No excuse for this.
|
| Imagine a library of books where every book over 5 years
| old is burned.
| driverdan wrote:
| That's not a reasonable comparison. A more accurate one
| would be something like having a 25 year old 12V battery
| drill and expecting the manufacturer to still make and
| sell the NiCad battery pack it used. Sure they could do
| it but it doesn't make any sense. Technology has moved on
| and there's no consumer demand for it.
|
| I agree that Apple and other companies are too aggressive
| about breaking compatibility but it's not the same thing
| as tried and true physical objects.
| ryandrake wrote:
| This is not a good comparison. Nobody is trying to use a
| new battery. They just want old battery to continue
| working as it has. Code does not rot like batteries wear
| out. Companies deliberately break compatibility, and then
| they blame arising problems on "code rot".
|
| Changing icon should not require a new build. A new build
| should not require iPhone X support. iPhone X build
| target should not require Xcode 9. Xcode 9 should not
| require macOS 10.12. OS update should not break old
| Unity3D. Upgrading Unity should not break builds.
|
| These are all examples of shitty engineering decisions
| that throw backwards compatibility under the bus for
| shaky (expedience, mostly) reasons.
| voakbasda wrote:
| You deserve more upvotes, because your analogies are not
| far from the truth. We are living through a black hole of
| history, where valuable information is being destroyed at
| unbelievable rates by virtue of it becoming completely
| inaccessible through the planned obsolescence of
| incessant upgrades.
| goosedragons wrote:
| We basically have that with the way publishers license
| ebooks to libraries. :(
| UnpossibleJim wrote:
| Yessssss..... come to the Linux community. Become one of
| us... one of us. There is no better time than now. One of
| ussssss. =)
| st3fan wrote:
| It is already very time consuming to stay up to date with
| Apples ecosystem. Swift evolves. Xcode changes. The runtime.
| The App Store. The APIs evolve. SwiftUI is radically
| different every year.
|
| Throw something like Unity in the mix and now you have even
| more things to keep up to date.
|
| You can say well that is just nonsense. My app is finished.
| But is it really? what if you actually need to do a critical
| bug fix. Or something to be compatible with new hardware?
|
| There is no simple answer here. But one thing I've learned is
| that staying as "standard" as possible is a huge huge
| advantage. Apples upward path is mostly manageable.
| tedunangst wrote:
| The longer you leave the yak unshaved, the longer it takes to
| shave it.
| emsy wrote:
| My windows is full of bald yaks.
| franknine wrote:
| Working on games with Unity for nearly a decade, the
| standard approach is to defer upgrading Unity as long as
| possible. Generally we stay on the old LTS (Long-term
| support) version until it's no longer supported. Latest
| version and new LTS are very unstable with game crashing
| bugs on certain platforms that I had to spend weeks to
| track down and spend weeks to convince Unity QA there is
| actually a problem then wait for months to get it fixed.
| It's better to just stay away from the latest and greatest,
| having other people do the demining.
| Wowfunhappy wrote:
| Games aren't like other software. People are still playing
| Psychonauts even though it hasn't been updated in a decade.
| Double Fine doesn't have the resources to go in and update
| the game engine every year.
|
| (I'd argue there's more room for this in non-game software
| as well, but _certainly_ for games...)
| verelo wrote:
| Sometimes recompiling into a new version of Xcode is required
| and that can result in very painful edits. While locally you
| can do whatever, apple often requires you to be using a very
| recent sdk (sometimes for good reasons like OS security of
| privacy changes)
| ploxiln wrote:
| -Werror is your mistake here. You can still fix warnings when
| you see them with a new compiler, without using -Werror to
| cause complete build failures except with a specific set of
| specially accommodated compiler versions.
| [deleted]
| kazinator wrote:
| If you set warnings to errors, and upgrade your compiler from
| time to time, you're asking the compiler people to help find
| hitherto undiscovered issues in your code using the latest
| diagnostic tools that they have come up with.
|
| If you don't want to be informed, then don't do that. But those
| issues could be real bugs.
|
| For instance, one fine day GCC got the ability to diagnose
| situations when the indentation of an nested if statement is
| deceptive compared to the actual precedence of the clauses. So
| if someone had warnings as errors, and had such a statement,
| then their build stopped. If that was a real bug, they were
| grateful.
| gnubison wrote:
| Please, please, please don't do this for end-user compiled
| software, because someday they're going to be using a more
| modern compiler than you and their build is going to break
| because of new warnings that you couldn't anticipate.
| slavik81 wrote:
| I've had to remove deprecation warnings because downstream
| users enabled warnings as errors in their releases. They
| could fix newer versions of their software, but being able
| to build old versions on new dependencies was a
| requirement.
|
| The solution was to introduce a deprecation message that
| wasn't technically a warning, and warn about the upcoming
| depreciation warning.
| lupire wrote:
| When do end users compile software but don't want to fix
| bugs?
| ploxiln wrote:
| New warnings usually do not indicate real bugs. Sometimes
| they do, but usually they are false positives. -Werror
| causing a build to fail is strictly worse than the
| alternative (working roughly as well as before, sometimes
| slightly better or worse due to new optimizations). This
| is the direct cause of "software decay" here. The
| software would not "decay" nearly as much without
| -Werror.
|
| Often a technical linux user will want to download a
| source tarball for a particular version of a utility or
| program, and build it on or for a particular linux distro
| they're using. They usually do not want ad-hoc
| modifications done to the source of all the specific
| utility versions they compile for their system this way.
| kadoban wrote:
| When the bug they're being forced to fix does not affect
| them. This can happen when they want to make some other
| change, or maybe they don't even need changes, they just
| need a build that doesn't exist.
| lolinder wrote:
| Is there any reason why the user in question couldn't turn
| off warnings at that point if they don't want to bother
| with it?
| SilasX wrote:
| I was really upset when I ran into this problem with Docker.
| Like, I thought the whole point of virtualization was that, no
| matter how old it is, it will Just Work, so long as the
| virtualization software works, and it has enough resources.
| It's supposed to _sidestep_ the problem having to constantly
| patch everything that might have changed since.
|
| Then one day, our startup brought some new employees on, who
| read the README and ran the indicated Docker command ... and it
| failed with a mysterious bug requiring dev resources to debug!
| The exact thing you try to avoid by freezing the machine
| environment.
|
| It turned out that Docker had silently pushed a backward-
| incompatible change in the format of docker-compose YAML files.
| emsy wrote:
| It's fine. I mean Apple refunds you if the App you bought gets
| removed, right?
| aSithLord wrote:
| only a user having the choice to sideload or not can solve the
| issues of the AppStore.
| ronenlh wrote:
| Similar current Twitter thread on the same issue:
|
| https://twitter.com/lazerwalker/status/1517849201148932096?s...
| aeturnum wrote:
| As with so many Apple policies this is perfectly understandable
| but becomes unacceptable because they monopolize access to
| applications on their platform.
___________________________________________________________________
(page generated 2022-04-23 23:00 UTC)