Talk:iOS version history

Semi-protected edit request on 26 July 2024

iOS version updates (if there are any)07:07, 26 July 2024 (UTC)07:07, 26 July 2024 (UTC)~ Riskofspam (talk) 07:07, 26 July 2024 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Left guide (talk) 07:25, 26 July 2024 (UTC)

Semi-protected edit request on 27 July 2024

To update list (if any) Riskofspam (talk) 23:50, 27 July 2024 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Jamedeus (talk) 00:01, 28 July 2024 (UTC)

iOS version 18 102.176.94.129 (talk) 11:38, 29 July 2024 (UTC)

The page now has 18.1 beta 2, although that came out after 2024-07-29, so that wasn't what was being referred to. The 18.0 betas are all up to date. Guy Harris (talk) 22:18, 24 August 2024 (UTC)

The "Hardware support" section, again

Yet again the Hardware support section has been removed with no proper reasoning or any discussion over the matter. Not only ignoring previous consensus, but also running afoul of guidelines. I'll react to the reasoning given in its entirety, but much of it will be repetition from the previous couple of discussions...

once again remove these, these are genuienly becoming incredibly unwieldy, and are a maintenance burden. - I've got good news, if you feel like something is becoming "incredibly unwieldy" and "a maintenance burden": you don't have to maintain it. Other people will. As a matter of fact, it was such a burden that it took me 1 minute to add the iPhone 16 earlier this month, it took me 2 minutes to add iOS 18/iPadOS 18 back in June to both templates. I wouldn't call that a burden or unwieldy. These tables are practically as simple as they can get: just cells. No rowspan, no colspans (except for the iPad), no ridiculous complex structures like actual unwieldy tables like those found on Apple silicon for example. Not only that, but something becoming "unwieldy" is not a reason to remove it. It's a reason to split. Speaking of which...

what happens in 10 years when we're at iOS 28 and iPhone 26? these templates are going to become incredibly hell-ish to maintain (more so than they already are) - Then when we've reached that point, we'll split them. It's that simple. A split could be made based on either the hardware or software. E.g.: everything before and after the iPhone X in their own template, or iOS 1-9, 10-19, etc. in their own template. It's actually very simple. Having said that, given that other articles like the MacBook article don't even mind with tracking 30 different devices across 17 different macOS versions (in a much more complex table), I do not think this is any concern right now. Maybe when we get to iOS 20 or iPhone 20.

quite frankly they don't belong here. his article is a chronological history of iOS releases, these templates genuinely do not belong here - Previous consensus reached in the talk pages of other articles to move them here says otherwise. But also, you've previously claimed that these tables duplicate content elsewhere described on the article (with which I frankly do disagree, because again: presentation matters and that information it duplicates has still not been actually written down in the first place), but that would imply that these sections would have to go too. Historic hardware support for what hardware the OS supports does however feel very on-topic for a version history article, though.

What I then take further issue with is that if you truly believe these tables are unwieldy and a maintenance burden, just removing them from this page won't solve any of that. They still exist, they still have to be maintained. Then adding them back as links in "See also" also runs afoul of the guidelines on how we should use templates. Templates are not articles, we shouldn't link to templates as if they are. The reason they are templates is because people believed that these tables were useful for multiple articles.

We've previously had discussions about this, numerous times at this point, and while you may say there was no consensus reached, everybody else agreed that these tables should remain (or at worst were indifferent about it). I'm frankly tired of doing this dance every 6 months, which at this point I think is fair to guess is exactly what you're aiming for: do this over and over again until people are just tired of telling you not to. As a matter of fact, last time around I predicted exactly that this would happen again. And here we are... At least this time you brought some mildly unique reasons to the table, but it is becoming extremely hard to take any of it seriously, because this is just - yet again - throwing a bunch of arguments at the wall and hoping something sticks... YannickFran (talk) 11:50, 14 September 2024 (UTC)

The problem with these templates lie not just in its long term maintenance burden, but also the fact that the more these templates are added to, the more they contribute to the overall include size limit. I know what you're going to say about the include size limit, and how it basically doesn't matter, or that the templates don't significantly contribute to it, however the include size is important. It reflects the maximum safe size for articles, and templates add quite a bit more to the include size than just raw text due to the additional code they import into the article. The tables also do not contribute to the article's encyclopedic quality in any way. This article is genuinely a mess as is, and if it is ever going to meet encyclopedic guidelines and standards to avoid facing another potential AfD, unnecessary templates shouldn't be included. Hardware support isn't within the scope of a version history article, you don't see any other version history articles with these kinds of templates, now do you?

Another thing, you have made the vast majority of edits to those templates, therefore you are personally biased towards the templates existing within the article. You can't defend the existence of your own template and reinstate them. If other people can provide valid, and I mean FULLY valid reasoning behind wanting these templates to be present on the article other than just "oh its useful" (WP:ITSUSEFUL; while this guideline generally applies to deletion discussions, I would argue that it is relevant here too as just because someone finds something to be useful doesn't mean that its existence in an article is fully warranted) then I will genuinely re-consider. But until then, stop reverting my edits to reinstate a template you have made the vast majority of edits to, especially when in my eyes these tables do not help the article reach encyclopedic standards. Constantly fighting over these templates doesn't help improve the article either. - Evelyn Harthbrooke (leave a message · contributions) 21:46, 14 September 2024 (UTC)

The problem with these templates lie not just in its long term maintenance burden, but also the fact that the more these templates are added to, the more they contribute to the overall include size limit. I know what you're going to say about the include size limit, and how it basically doesn't matter, or that the templates don't significantly contribute to it, however the include size is important. It reflects the maximum safe size for articles, and templates add quite a bit more to the include size than just raw text due to the additional code they import into the article. - Yeah sure, and we're a far way from that limit. So no, it does not matter. And once again, if that does become an issue, the solution isn't to just drop content, it is to split the article where it makes sense.

The tables also do not contribute to the article's encyclopedic quality in any way. This article is genuinely a mess as is, and if it is ever going to meet encyclopedic guidelines and standards to avoid facing another potential AfD, unnecessary templates shouldn't be included. - Come on now, you know very well that the AfD was because this article was one massive copyright violation. These tables had absolutely nothing to do with it.

Hardware support isn't within the scope of a version history article, you don't see any other version history articles with these kinds of templates, now do you? - There also is no other version history article where the software and the devices it supports are so closely tied together. And yet again; these tables originated from another article where it was decided at the time to move them here. By consensus.

If other people can provide valid, and I mean FULLY valid reasoning behind wanting these templates to be present on the article other than just "oh its useful" - People already did that in every previous discussion we've had about this. You continuously ignoring anything anyone, including I, said doesn't change that.

As for the you have made the vast majority of edits to those templates, I've already responded to that. But you already knew that this argument was nonsense... YannickFran (talk) 21:59, 14 September 2024 (UTC)

For the record, no, the AfD wasn't because of the copyright violations, it was because the article was violating WP:NOTCHANGELOG, the copyright violations were another issue that was addressed awhile ago. And sure, we can split the article, but that doesn't help when the hardware support templates add basically 300,000 bytes if not more to the total article size, which increases load times, especially on slow Internet connections. My point is that having a billion tables don't help an article's encyclopedic quality, and they also cause a user to have to scroll for longer to get to the bottom sections of the article, such as References and See also. Arguably even now this article is still not encyclopedic material, because a lot of the text is repetitive. The problem is, because so many editors have stopped contributing to articles like these, this article is stuck in a basically stagnated state. I only ever see this article be updated when a new iOS version is released, usually not at other times, especially not when it comes to expanding the article with new content to help it better meet encyclopedic standards, especially for stuff like references.

And it's not nonsense. You have significantly contributed to that template. I've seen the edit history. - Evelyn Harthbrooke (leave a message · contributions) 22:46, 14 September 2024 (UTC)

For the record, no, the AfD wasn't because of the copyright violations, it was because the article was violating WP:NOTCHANGELOG - Sure, but you may notice, that these tables still have nothing to do with that either.

And sure, we can split the article, but that doesn't help when the hardware support templates add basically 300,000 bytes if not more to the total article size - 300.000 bytes out of a limit of 2.000.000. That is far from problematic, and once again, if it does become problematic, it's reason to split the article. Not to just blatantly remove content.

and they also cause a user to have to scroll for longer to get to the bottom sections of the article - Sigh... come on now... Now they are too long? Are these seriously the arguments this discussion has devolved to?

Arguably even now this article is still not encyclopedic material, because a lot of the text is repetitive. - Then place a template requesting improvement at the top of the article. This has nothing to do with these tables.

The problem is, because so many editors have stopped contributing to articles like these, this article is stuck in a basically stagnated state. I only ever see this article be updated when a new iOS version is released, usually not at other times, especially not when it comes to expanding the article with new content to help it better meet encyclopedic standards, especially for stuff like references. - Again, not a reason to remove anything. It's hilarious that you take issue with this article not being kept up to date, but then demand the removal of 1 of the only sections that is.

And it's not nonsense. You have significantly contributed to that template. I've seen the edit history. - Again, these tables predate their template for years. My first edits to them were to appease to your commentary about their size. You don't get to then say that because I made changes you requested, I'm now "to involved and biased". That is downright ridiculous.

Note also how, yet again, you just repeat yourself and completely disregard any argument brought now, and back then. YannickFran (talk) 09:31, 15 September 2024 (UTC)

It should also be noted that the last time someone asked to reinstate these templates, someone other than me literally said that the discussion failed to reach consensus. There is no consensus to keep these templates. Most were indifferent, and the people that said they were relevant, either stopped contributing to Wikipedia, or stopped contributing to this article. The editors actively contributing to this article have significantly shrunk in number, and I'm not going to ping editors who no longer contribute to this article to form an opinion on this. You will be hard pressed to find a significant majority who agree that these templates are useful anyways or that these templates contribute to the article's encyclopedic quality, therefore I see genuinely no reason for these tables to exist. - Evelyn Harthbrooke (leave a message · contributions) 21:55, 14 September 2024 (UTC)

I feel like you are misremembering things. Because that person (@DFlhb) very specifically said: "I agreed with someone else to delete, but two people isn't remotely a binding consensus" (you'll remember this quote because I've quoted it to you before) after which they themselves reverted their removal. "either stopped contributing to Wikipedia, or stopped contributing to this article" but that isn't any reason to disregard their opinion. I've said it before and I'll say it again here: you don't get to restart this discussion over and over in the hopes everyone is just tired of this, then conclude "see, nobody cares anymore, that's consensus". In previous discussions, multiple people have engaged in this conversation, not a single one argued for their removal but you. So I find it extremely ironical that you then say I'd be hard pressed to find people that agree that these tables should remain. The archive of this talk page is filled with them. You on the other hand seem to have a hard time finding anyone who actually agrees with you. YannickFran (talk) 22:08, 14 September 2024 (UTC)

In addition to the edit summary:

re-instate, as my edit summary was incoherent: you have done the vast majority of work on these templates, you are biased toward these templates existing. therefore, you are too close to this. I made a compromise by allowing them to still be linked to in See also, however they should not, and I mean should not, be allowed to be displayed within the article itself. they are severely inflating the include size, even moreso than the last time we had this argument. they do NOT belong on this page.

This user decided that it was more appropriate to discuss article content on my talk page instead with this message:

Please respectfully stop adding those tables back to the iOS version history article. They have no reason to exist. They can be linked to, but they are unwieldy templates, that serve no valid purpose showing up on the page itself, very few people actually find use in them, and they hold no relevance to the overall subject at hand. No other version history article on Wikipedia has these kinds of templates, and I find no issue with them being linked to in See also, but that's the extent of what it should entail, as those templates make the article look ugly and visually incoherent. You have also done the vast majority of work on the templates, so, therefore you are biased and are too close to this.

Since I think that such discussions must be had on the talk page of the relevant article, I'm pasting this here for later reference. With that said...

I'm sorry... What? You've failed to reach agreement to remove these tables from the article multiple times over now. There have been instances twice over where random IP users jumped into the talk page to ask why they were removed. Do you understand how high of a bar that is before people bother to comment on it? So where exactly do you know "very few people actually find use in them" (and once more; absolutely not a reason to remove them). Also, why are you taking this discussion to my talk page? That's not the place where this has to be discussed, completely inappropriate. I don't care if you personally think the tables look ugly. These kind of tables are commonplace. If I think the Infobox template is ugly, does that warrant me removing that too? No, because what I do or do not find ugly isn't an argument to remove information (but yet again, we've been over this already).

Yet again you are just repeating old arguments without even responding to my and other's comments from back then. You are just repeating yourself over and over again and ignoring everything everyone has told you you were wrong about.

And by the way: You have also done the vast majority of work on the templates. You are joking, right? When you began to remove these tables without consensus the first time around, I'd never even made a single edit to any of the 3 tables in question. My first edits were to address your complaints about their size and complexity to the extend that that was possible (and frankly, yes, I did agree with you at the time that they were needlessly complex as a result of including SoC information, which was then removed). Not only that, but the changes I've made to them where entirely structural and can literally be summed up with "inverse the axis" for the iPhone and iPod tables, and "group similar iPads together" for the iPad table, not even close to the "vast majority" and for later iPhone and iPad releases, after that it was literally 1 minute of work whenever a new iPhone, iPad or iOS version came out. Not only that, but these tables predate the creation of their templates by years. So what exactly are you talking about?

You don't get to come here and demand these tables to be changed, then demand them removed because the person who made the changes to compromise with your requests is now, in your sole opinion, "biased and [...] too close". You are literally just saying "you are against my opinion, therefor you are biased, therefor I am right". Maybe before you tell someone else they are to biased, look into a mirror. YannickFran (talk) 21:58, 14 September 2024 (UTC)

As you continue to ignore this discussion further and instead still attempt to act as if there is a consensus here, I've undone the changes you've made to the support tables as per WP:QUO for many reasons, but ironically, these reasons often go straight against the issues you've raised before (namely accessibility and "how good they look"). Also because you continue to try to WP:ATORC and ignore the policies of WP:NOCON (although I'd say there is a consensus, it just isn't in the favor of your edits).

1. You've made accessibility considerably worse. Not only shouldn't we collapse content without a good reason (and you personally not liking what they look like isn't a reason as per WP:JDL), it also means that some people straight up won't be able to view them at all, it goes straight against the guidelines at MOS:DONTHIDE.
2. Further, you've removed the caption and replaced it with "<device> software support". Which also introduces an accessibility issue: the table's captions no longer properly describe what they do. You've left 0 context for what these tables are. iPhone software support for what? Furthermore, these aren't titles, they are captions. They aren't meant to be short, they are meant to describe what the table contains.
3. By removing the OS name from the table entirely, even for readers that don't need accessibility tools, there is now no way of knowing what these tables show. "Version" is not a proper descriptor.
4. By shortening the name of the devices, you've now also removed any context for accessibility tools, who will now just read "3G", "5", etc. for the various iPhones.
5. Unique to the iPhone table; also by removing the names and removing the left alignment, you've now made the model column visually bussy and in-cohesive as the reading line now jumps left and right depending on the model name and if there are notes or not. Which is both an accessibility issue, and generally just visually unpleasing.
6. Setting a forced width results in the tables becoming abnormally long on wider screens, also reducing accessibility. And while I myself set the tables from width to min-width to prevent needless word breaks, fact of the matter is that this is completely unnecessary. These tables can be as wide as they want to be.
7. Collapsing the tables also seems to completely negate any reason (how unfounded they may have been) for making any of the other changes at all...
8. These tables are templates that can be included anywhere, it isn't appropriate to just collapse them elsewhere because you don't like them here.

However, there are other issues worth addressing, although more related to behavior than with content.

• You decided to practically instantly undue further improvements I've made to these tables. Not only inappropriate, but you also decided to call them "non-constructive" edits ([1], [2]) only to immediately apply the same changes yourself. That is ironically non-constructive and downright WP:DISRUPTIVE and WP:GASLIGHT.
• Not only that, but in this very article you also decided to undo my edit changing "iPhone 2G" to "first generation iPhone" ([3]) claiming iPhone 2G is the most common name. Nobody calls it the first generation iPhone.. As I already pointed out in my edit summary reverting this revert; not only did the old version tables already refer to it as such, the main iPhone article does so too, as does the iPhone (1st generation) article, and more importantly: this article does so too in the Overview section. But mayhaps even more telling: you called it that when you edited the support table, you didn't replace it with "2G", you replaced it with "1st". Never mind that this is the common way to do this across all Apple devices.
• Calling me "toxic" while ignoring everyone's opinion, and any request for discussion (that isn't just answered by you with endlessly repeating the same argument over and over again without acknowledging other people's counterpoints) is simply WP:STONEWALL.
• Furthermore, I've already made concessions in this discussion when it started the first time around. Not only do you seem to engage in WP:BADFAITHNEG here by continuing to demand further concessions at best or downright pushing through your opinion at worst, despite the consensus not being in your favor at all in the first place, you've also decided to then proceed and hold these concessions against me to completely dismiss anything I say because I am "to biased".

Frankly, I don't see how any of this isn't disruptive behavior from your side, because all of this already matches a couple of bullet points mentioned at WP:DISRUPTSIGNS.

I have requested (yet again) a WP:THIRD, and for whomever may answer that, I'd like to point out to that user that this conversation was previously held at Talk:iOS version history/Archive 7#Missing hardware support table?. To make up the tally; @User34522938 requested the table to be restored after it was removed, with myself, 2A02:A020:53:755D:E8B3:A296:3F13:37AC, @Brusquedandelion agreeing that they should remain, @Mesocarp countering the arguments leveled for their removal but mostly remaining neutral, and @DFlhb also counters the argumentation for their deletion in that conversation, but more relevantly is the person who originally removed the tables, as well as the person to first restore them again saying "I agreed with someone else to delete, but two people isn't remotely a binding consensus". And while 3 for, 2 neutral and 1 against keeping them might not rise to a solid consensus to keep them (although I'd say otherwise), it sure as hell is not a consensus to remove them. It's also worth noting that @Evelyn Harthbrooke has a history of ignoring consensus on this very article. YannickFran (talk) 19:15, 16 September 2024 (UTC)

Treating a 3-2-1 vote as consensus is not how consensus works. You say there was a consensus to keep the templates, but there wasn't. A 3-2-1 consensus is very mixed, and non-conclusive. Therefore you can't argue that there was consensus in place to keep the templates, and that was the main point of the original consensus; to determine whether or not the templates were worth keeping. Not whether or not to restore them. Therefore your entire reasoning about there being consensus regarding keeping the templates goes out the window, as there was never a solid conclusion or consensus, despite what you may argue.

I'm going to address your points, but they might not be in order:

1. There was no "agreed upon consensus" in your edit summary reverting my template changes despite what you may claim. You can't possibly argue that there was a consensus in place for the existing template styling when a consensus vote has never even been held on said styling. Arguing consensus when there never was is lying, and acting in WP:BADFAITH, the same thing you're accusing me of, which I am not. I am not arguing in bad faith, or acting in bad faith. I am genuinely just trying to improve the article, and in my opinion, the templates being visible at all times isn't necessary for the core content of the article.
2. I reverted your edit to the iPhone 1st gen wording without thinking, and I apologize for that. That's why I used "1st" in the iPhone OS 2 table, and I was going to reinstate 1st in the iPhone OS 2 table but I got too tired and that is when I hopped off for the night.
3. Regarding accessibility, there are pretty good indicators that the tables imply the various device generations without having to say "<Device>" for each and every generation. Especially when the template caption itself mentions the device. So how could my changes possibly be bad for accessibility when the context is already implied? It's an iOS version history article, talking about iOS versions, on various Apple devices, and the templates in question are named "<device> supported OS release". You don't need more obvious context than that when it's already implied to a heavily significant degree. I am all for accessibility but there's no reason to be super obvious in the templates repeating "iPhone" or "iPod touch" over and over again. It's redundant, especially when there were already indicators.
4. "Version" is a valid descriptor, it's already implied quite heavily that it means the version of iOS or iPadOS, so how can you possibly argue that it isn't a valid descriptor when it very obviously is to anyone who looks at the templates? I don't understand your point because of that.
5. There were no issues from what I noticed regarding the iPhone models regarding the model names and the notes associated with them, unless maybe that was an issue caused by the reduced width and the changes Wikipedia has made to Vector, adding text size options and changing the default text size to be bigger than it used to be; I didn't test because I don't use the "Standard" text size, I use the "Small" text size as that's what I've been used to for basically as long as the new Vector skin design has existed.
6. I set width because of the fact that the captions shrink when there isn't a min-width in place and the tables are marked as collapsible, making them visually inconsistent when collapsed and uncollapsed, which was why I did that. And arguing that they become "abnormally wide" on wide screens is untrue, incoherent, and invalid, because the "width:" parameter enforces a strict width, a width deemed necessary for the template to be fully readable, and is why I set the width to roughly the same width prior to the collapsible changes. So you can't argue that the tables become abnormally wide, when they do not. Unless you're referring to me setting the same width for all of the templates, in which case I did that for visual consistency, but they still aren't "abnormally" wide, I say that as someone who has multiple big displays at high resolutions. So you can't argue that either.
7. Also, sure, the templates can be added anywhere, however this point is pretty redundant when they're only used on one article: this one. They don't really serve a purpose being added to any other article.
8. Regarding the collapsing of the templates, I tested this on both mobile and web, the templates don't disappear when marked with "mw-collapsilbe mw-collapsed". I have no idea why WP:DONTHIDE still has that, however it probably involves more complicated templates, or maybe its a relic from when Wikipedia's mobile skin wasn't as robust as it is now. If they completely disappeared when those classes were set, then all of the iOS version overview tables on iOS version history would straight up disappear too when on mobile, however they do not, so WP:DONTHIDE doesn't apply here. It also doesn't apply because those templates aren't paramount to the core content of the article, as I mentioned in point 1.
9. Perhaps "<device> software support" wasn't the best idea for the caption names, and I do personally regret changing the captions to those.

I apologize for the unkind edit summaries I have been using, I am just frustrated and I struggle to show my frustration in constructive ways sometimes due to my underlying mental conditions and state, and I profusely apologize for any that targeted you unkindly. I'm never intentionally trying or wanting to act in bad faith, as I genuinely and fully realize that that isn't constructive. I just need to work on finding better ways to express myself. Again, I profusely apologize. Throughout this whole thing I've only been trying to find a way where everyone can be happy. I do believe that perhaps these templates have a use, so I'm not going to argue for their removal anymore, but they should at least be made collapsible so they aren't visible on screen unless absolutely necessary. Although instead of using captions I think the tables should move to using a style similar to iOS version table where the title is inside the table itself instead of being outside the table, as I believe it would add some visual consistency. - Evelyn Harthbrooke (leave a message · contributions) 21:38, 16 September 2024 (UTC)

First of all, the status quo was these tables being here. You've repeatedly lied about me being the first one to add them (despite the edit history clearly showing otherwise) as well as for how long they were gone (3 weeks before their original removal got reversed by the same user that removed them). The discussion was about whether or not they should be removed. You've repeatedly claimed there was consensus to have them gone despite lacking any discussion and have repeatedly disregarded people previous opinions on it by restarting this discussion over and over again. You may also notice that I point out that while I believe this is as close as it gets to reaching some sort of consensus, I make clear that the argument can be made that it isn't, and that I myself don't believe its a solid consensus. What it certainly is not, however, is a consensus to remove them.

1. I never claimed there was. I said you were making changes subverting the discussion.
2. Okay.
3. But you removed that from the caption, so no, it wasn't clear. Your edits left no indication to screenreaders (or even normal readers) what these tables were actually trying to convey without clicking on the links. Captions are an important tool to describe what a table is. For that same reason I've restored the captions that you replaced with table headers. Do I think what you did looks much better? Absolutely. But table headers and captions are 2 completely different things. I used to do this to tables too... until I started using screen-readers and realized how that degraded the experience for people that rely on them. Besides, for tables that aren't collapsible, there is no real reason for it in my opinion. When they are collapsible (and collapsed by default) it helps make the table visible (where using just a caption makes them disappear in the text), but that isn't the case here.
4. "Version" is not a proper descriptor in the sense that the rows underneath it are talking about different OSes. Regardless, it doesn't save space. Generalizing it is of no benefit.
5. The issue with the notes was with how the note link next to the titles pushed the names left and right relative to those above and below it. There wasn't an issue with the notes themselves. Sorry if that wasn't that clear.
6. Width only does that if you define an absolute value, a percentage however is relative and causes these tables to become abnormally wide when using the old Wikipedia theme or the wide variant of the modern theme on a large monitor.
7. They are used for the iPadOS version history page at least.
8. People still use old Wikipedia themes and apps.
9. Okay.

I'm thankful for the apology. As for the headings, I've already explained in point 3 why that isn't a good idea, I hope you understand that.

And for the record, please keep working on this page. YannickFran (talk) 17:18, 17 September 2024 (UTC)

Allow me to go deeper in on the caption vs header issue. In the tables as they are now, asking a narrator tool like Windows Narrator to describe the current cell will make it say "9, iOS version, column header". The change you made resulted in Narrator describing the cell like this: "9, Version, Hide, View this template, Discuss this template, Edit this template, Supported iOS and iPadOS versions on iPad, column header". I hope that helps clarify why doing it through a header is problematic.

Having said that, I would argue it isn't as much of a problem on tables like the version table because just reading out the content already gives you a clue what is being described, but for tables like these - where the data is a matrix - that isn't the case and you need to ask Narrator to read the headers (both for rows and columns), and this makes that unnecessarily long. It also means Narrator no longer knows what the table is about before going into it.

Furthermore, WP:HEADERS explicitly calls for the use of captions.

As for the percentage width, this is what the tables looked like with the width set to 27% on a 4K monitor. I hope that also properly illustrates that issue. YannickFran (talk) 18:17, 17 September 2024 (UTC)

Okay @YannickFran, I guess I might as well consider myself as responding to the 3O request as long as I'm showing up here. :P Sorry I didn't say anything here when you pinged me earlier—things have been really crazy in my day-to-day life recently and I didn't look closely enough at that notification. @Evelyn Harthbrooke, a "3-2-1 consensus" may be rather mixed, but an RfC would at least have a chance of presenting something much more definitive. I've started a new section to that effect below. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 00:10, 21 September 2024 (UTC)

No worries, the ping was mostly in case anyone of the mentioned users felt like commenting, that they might and just in case I was misconstruing their position, I wasn't actually waiting or expecting an answer. :) YannickFran (talk) 12:14, 22 September 2024 (UTC)

Version support table accessibility

With the ongoing dispute in the version support tables, I'm opting to hold this conversation here in the talk of their parent page to not fracture this between 3 talk pages.

The table headings and captions were good as they were, which is why I've restored them. The changes made go against MOS:ACCESS, MOS:COLHEAD and the guidelines as described in WP:HEADERS, as well as against general HTML rules and best practices. I can also confirm that this behavior is also problematic in at least ChromeVox. Without captions and just clicking into a table would just say (for example, it depends on your screenreader) "Yes, column 16, row 14" and never even mention what the table is about when there is no caption. Body text is not an alternative to captions. It's also why images always have captions despite the body text describing what the image is about (at least, when done properly). Screen readers that do have more advanced understanding and controls for reading tables will however all have the same or similar behavior described above of Windows Narrator (some will by default read whether or not a link has been visited, making this issue even worse).

Furthermore removing the OS names when the names change through the years has no benefit other than just making it more unclear. The only minor issue I see is that "iPhone OS version" pushed its child columns to be wider than they really had to be. To solve that, I've dropped "version" from these headings cells, I think "9, iOS" brings the point across well enough for both humans and screen readers. For the iPad table I've added a note to the heading that version 3.2 was called iPhone OS, labeling 3 through 12 as "iPhone OS / iOS" is misleading. If that wasn't where you concern came from, then I really don't see what this was trying to solve at all and would love to have an explanation for it.

As for including iOS 16 in the iPod Touch table, the user who did that pointed out that it made clear to users that support completely stopped after iOS 15. I think that is a valid point, but better left to a note, which is why I've added a note to iOS 15 heading explaining that this was the last version of iOS for iPod Touch devices.--YannickFran (talk) 07:25, 18 September 2024 (UTC)

Agree, the last change at Template:IPhone supported OS release (moving the table caption into a wide header cell) clearly goes against MOS:TABLECAPTION. That is an explanatory subpage of Wikipedia:Manual of Style/Accessibility, which, like the rest of the MoS, is a generally accepted standard that editors should attempt to follow, though occasional exceptions may apply.

I don't really understand the claim that WP:<insert shorthand here> policies aren’t enforceable. Technically, nothing is blindly enforceable, but policies and guidelines should reasonably be followed if there isn't a clear reason not to do so. In this case, if the only arguments for the change are stylistic choices and the fact that other articles also don't follow the MoS, there isn't enough of a justification for departing from it. Chaotic Enby (talk · contribs) 16:31, 20 September 2024 (UTC)

Proposal to split article at iOS 20 release

This is a long term proposal where I propose that the article (and its associated templates) be split beginning with iOS 20 in 2026, which means this article will stop having new iOS versions added to it at that point, in favor of a forked article containing iOS versions beginning with iOS 20 and probably ending at iOS 39 (if we get that far). As this article will begin to get unwieldy at that point, especially with all the version tables. All of the templates will also be split as well, such as the hardware support templates, which I have added back after a brief removal (and a not so kind exchange as seen above 😔) but collapsed by default to avoid unnecessary scrolling, and that way its not in viewers faces. But yeah, after the release of iOS 20 in 2026, this article should be renamed to "iOS version history (versions 1-19)" and a new article be created titled "iOS version history (versions 20-present)", similar to how "List of <show> episodes" articles are split after a lot of seasons, such as with Law & Order: Special Victims Unit and The Simpsons. - Evelyn Harthbrooke (leave a message · contributions) 05:14, 16 September 2024 (UTC)

I think we should go more with an approach as done on macOS version history, Windows 10 version history and Windows 11 version history where the main article does discuss all versions, but only in summary and leave the version tables to the main articles of the relevant version. Especially given that these articles already tend to have a version history table of some sort like the iPhone OS 1, iPhone OS 2 and iOS 7 articles. Those probably should be unified with the ones on this page through section transclusion or moving them to a template either way. YannickFran (talk) 08:10, 16 September 2024 (UTC)

+1 for YannickFran's suggestion. Guy Harris (talk) 09:08, 16 September 2024 (UTC)

Actually, per WP:SPLIT, this may already be a more pressing matter and we cannot wait until iOS 20. The split policy states that at 8000 words an article May need to be divided or trimmed; likelihood goes up with size., we're right now at 7600 words and probably just 1 version details table away (the iOS 18 table alone may eventually push it into that number) from crossing that word count, if not also crossing into the 9000 words milestone which states that the article Probably should be divided or trimmed, although the scope of a topic can sometimes justify the added reading material. YannickFran (talk) 12:03, 21 September 2024 (UTC)

Planning an RfC/RfCs to settle the table format question(s)

So, after what seems like very extended discussion, there is still controversy over what should be done with the tables in this article. Recently at ANI the possibility was raised of settling the manner via RfC, so I thought I would try getting that discussion going over here. Here's what I gather at something of a glance, which might not be quite right:

• there are disagreements over two different types of table in this article, "hardware support" and "version support",
• over time, a variety of possibilities have been raised for the content and format of these tables, including "none", and,
• remarkably extended discussion has failed to settle the matter.

To me, the questions about whether these tables should be here at all is already a complex thing to take up in policy terms and hard to give a definite and obvious right answer to. The questions about how the tables should be formatted based on the MoS and so on are even more ambiguous and hard to settle based on written policy. In many ways, it's intrinsically subjective, has to take the specific sources for this article into account, and something that I think might be best just to solve by trying to establish some kind of solid consensus arount it here, based on whatever rationale people end up finding acceptable. It's been discussed so much that I think we're way past the point at which one or more RfCs would be justified.

Two things I think we might consider at this point are:

• Does anyone still feel the tables should be removed entirely, or has everyone come to agree that those tables should be there in some sense?
• What are the main different formats that have been proposed for "hardware support" and "version support" tables? Maybe we could write a representative sample for each format?

I think this would take us closer to being able to propose a good RfC or two that could put this whole debate to rest, if we're lucky. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 00:03, 21 September 2024 (UTC)

I answered on ANI that I believe that the tables should be removed, yes, based on my belief that they fall out of scope of what this article covers. List of iPhone models, List of iPad models, and List of iPod Touch models already cover significantly more in-depth the devices, their software support lifespan, and other characteristics of the devices to where I believe that those articles serve the purpose of showing the device's support lifespan a lot better than shoving "Hardware support" at the bottom of an article dedicated to covering the version history of iOS.

Another option would be to move these templates somewhere on iPhone, iPad and iPod Touch, to put the templates in a more prominent place, due to the sheer number of additional page views these individual pages receive compared to this article. So my opinion and stance on the matter is that these templates don't belong on this article due to this. - Evelyn Harthbrooke (leave a message · contributions) 00:22, 21 September 2024 (UTC)

Okay, so maybe it makes more sense to take up the question now of whether we should keep the tables. If they end up being moved or removed, the questions about format don't really matter. If I follow what you're saying correctly, it sounds like you're proposing three options: the tables should stay on this article, the tables should be removed and don't belong on Wikipedia, or the tables might belong on Wikipedia but not on this article (although they might be appropriate in some other articles).

The question of where else they should go might be hard to answer here; I think that would take more of something like, a more general RfC about these kinds of tables that was robust enough to hold up across all the relevant technical articles (which would be quite a feat). So, if we restrict ourselves for the time being to just this page, we're then left only with:

1. the tables should stay on this article, or
2. the tables should be removed from this article (to say nothing about whether they might belong elsewhere).

I'd say that's probably an easier question for people to take up in an RfC for this article. I think the question about whether these kinds of technical info tables belong in general is probably too ambitious to definitively settle in this forum. Maybe we should hope that it ultimately doesn't have to go that far. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 00:46, 21 September 2024 (UTC)

Yes, I agree with the options that you are proposing. Whatever conclusion the RFC comes to is the one I'll respect. These discussions have been going on much too long at this point with no solid consensus ever reached. - Evelyn Harthbrooke (leave a message · contributions) 00:54, 21 September 2024 (UTC)

Okay, we can see what other people say and then give it a try. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 01:01, 21 September 2024 (UTC)

I guess, I should specify, we should maybe have people pick between "kept in the article in some form" and "no tables with this kind of information period". If the tables are kept, it doesn't answer the question of how to format them; maybe the current formats shouldn't be kept, which is a question we can take up separately if we come to that point.

Of course, we actually have a choice between four options, I guess:

1. have "hardware support" and "version support" tables,
2. have only "hardware support" tables,
3. have only "version support" tables,
4. have neither "hardware support" nor "version support" tables.

Am I correct in saying that the "hardware support" tables are meant to show which devices support which iOS version, and the "version support" tables are meant to show the release dates, EOL, and major features of each version? Like, what regardless of what format is used or what supplementary information might be included? We can make that part of the RfC as well, so it's clear what sort of content we're discussing. Also, I guess, just be clear, it looks like the information in these tables is sourced from a mix of Apple's documentation and things like magazine articles and the like? 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 00:59, 21 September 2024 (UTC)

I believe the version overview tables, the ones with the "Overview of iOS x.x versions", should be kept, they provide details within the scope of the article, the tables I am referring to that don't really have a place, are the tables at the very bottom of the article, under "Hardware Support". The rest I have no issues with at all. They shouldn't be removed without a fundamental rewrite to the entire article. Speaking of this, the most recent AfD article was closed as keep with the expectation that this article would receive significant improvements to the way the article is worded and written, though those changes have never come, likely due to a lack of editors focusing on these kinds of articles.

To answer your question, the version overview tables show the release date, version number, supported devices, and major features in each iOS release cycle, while the hardware support tables strictly show the model and its span of support, e.g. how the iPhone XS shipped with iOS 12 and has gone up to iOS 18. - Evelyn Harthbrooke (leave a message · contributions) 01:07, 21 September 2024 (UTC)

Oh, okay, so it's only the "hardware support" tables? I guess, as long as no one else has a problem with the version overview tables, we can leave those aside for the time being. Sorry I got confused there. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 01:15, 21 September 2024 (UTC)

Yeah, it's only the Hardware Support tables I have reservations about. :) - Evelyn Harthbrooke (leave a message · contributions) 02:47, 21 September 2024 (UTC)

I do not believe the version overview table is at discussion, no. YannickFran (talk) 11:58, 21 September 2024 (UTC)

No opinion on whether the tables should be included, but the question of whether (if included) they should have a caption or a wide header cell above the regular headers appears to be pretty conclusively answered by MOS:TABLECAPTION. Also, the "wide header cell" option leads to accessibility issues as described previously, notably for screenreaders. Chaotic Enby (talk · contribs) 04:57, 21 September 2024 (UTC)

Additionally, while the captions have now been restored, keeping the wide header and not moving the navbar out of that header still leaves that to be repeated when navigating through the table or asking a screen reader to describe the current cell with a screen reader. YannickFran (talk) 11:58, 21 September 2024 (UTC)

I believe they should remain. What devices an OS runs on is a property of the OS, not of the device. The device is static once it has launched. The OS is the variable, and thus relevant to its version history. If what version supports which hardware is out-of-scope of this article, then so is the "Device end-of-life" column in the "Overview of iOS versions" table and the mini tables within the "Overview of <OS> versions" tables, these tables are summaries and visualizations of that information. YannickFran (talk) 12:27, 21 September 2024 (UTC)

The device end of life is all the reader needs to grasp when a device is no longer supported. Those hardware support templates are overly technical. No matter how much you try and remove from them they're still overly technical and unnecessary to the core function of the article. Those tables are also inherently device related, not iOS related, because it relates to a device's lifespan. - Evelyn Harthbrooke (leave a message · contributions) 20:29, 21 September 2024 (UTC)

What exactly is "overly technical" about "does this version of the OS support this device"? That's a very simple question. People aren't stupid. YannickFran (talk) 12:24, 22 September 2024 (UTC)

Did I say they were? No. But having tables at the bottom of the article, that almost nobody reads, is counter to the goals the templates are trying to achieve. - Evelyn Harthbrooke (leave a message · contributions) 21:29, 22 September 2024 (UTC)

So you're just saying they are "overly technical" for no reason? Why are they "overly technical"? What do you base on that "almost nobody reads" these tables? Why would the position of these tables be "counter to the goals the template are trying to achieve"? That argument implies that you think they need to be more visible, yet you use that as an argument to hide or completely remove them. Note how you didn't actually respond to the question. YannickFran (talk) 11:59, 23 September 2024 (UTC)

The information they provide needs to be visible, but they don't need to be dedicated templates to do so. An "Initial devices" column could very easily be added to Template:iOS versions that shows when a device was initially supported by a given version of IOS, and it could do it in a more compact way that is more obvious to the user and doesn't require three (!) separate templates to do so. - Evelyn Harthbrooke (leave a message · contributions) 22:14, 23 September 2024 (UTC)

No, it would just require a bunch of notes and require users to compare data between multiple columns to know how long that actually was. But also, note how you didn't - yet again - answer any of the questions. YannickFran (talk) 06:37, 25 September 2024 (UTC)

The existing tables requires the exact same comparison. None of the reasons you are providing are valid enough to keep the tables. - Evelyn Harthbrooke (leave a message · contributions) 06:44, 25 September 2024 (UTC)

Not to mention the existing tables cause a shit ton of rightward drift, causing the user to shift their eyes a lot to process the information, whereas an "Initial devices" column next to "Device end of life" would require very little rightward drift, and would be more quickly consumable. It's not like Apple releases a billion iPhones or iPads a year, and the iPod touch has been dead since 2022. - Evelyn Harthbrooke (leave a message · contributions) 06:47, 25 September 2024 (UTC)

I dunno which devices this project supports in regards to accessibility besides what mw:Compatibility and mw:Accessibility say. Shall we ask at WP:VPT then? George Ho (talk) 17:34, 21 September 2024 (UTC)

I have just come to another potential solution: Adding a dedicated "Initial devices" column to the Overview table at the very top of the article; showing which iOS version premiered with each device. This would potentially render the need for dedicated Hardware support tables unnecessary, would be more prominent in the article as the Overview table is at the very top of the article after the lead instead of being at the very bottom of it like the current hardware support templates are, and would reduce the amount of templates that have to be maintained. It would also be easier to understand as it would be text, instead of X's and checkmark's. I just feel that this would be better and it would make the overall flow of the article better and the content would be more focused. It would also allow less scrolling to get to the other sections of the article, such as References. - Evelyn Harthbrooke (leave a message · contributions) 03:48, 22 September 2024 (UTC)

Sorry I've been a little quiet…I've been reading up on the existing debate to prepare a potential RfC draft, while things have been a little bit extra-busy in my daily life. I still have more to read but I think I've covered a lot of the major points by now. 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 🍉◜⠢◞ↂ🄜𝚎sₒᶜa𝚛🅟ම𛱘‎🥑《 𔑪‎talk〗⇤ 20:49, 22 September 2024 (UTC)

I have reinstated the non-transcluded iPhone OS 1 table.

We should not transclude sections from other articles. This has always been its own independent entity and should remain as such. The version histories on the individual OS articles were better suited to those pages because they were intended to be shorter and more concise, whereas we have more breathing room here. I have reinstated the old iPhone OS table on iPhone OS 1 and re-instated the non-translcuded iPhone OS 1 table here. Not to mention that the change that Yannick made breaks consistency with all of the other version overview tables and requires an editor to go to a completely separate article to edit the version table, which is counterproductive, not to mention blatantly unintuitive to future editors who may decide to contribute to this article. - Evelyn Harthbrooke (leave a message · contributions) 00:46, 25 September 2024 (UTC)