Talk:iOS version history

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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)Reply

  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)Reply

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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

  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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

My changes literally do NOT go against any of these policies. All I did was add an additional header cell for version, while keeping the caption. This discussion only applies to my previous change, where I removed the caption. But having a wide "Version" header cell with subheaders indicating iPhone OS and iOS versions does not go against any Wikipedia policies, if anything it adds stronger context that indeed the column relates to iPhone OS and iOS versioning. You are the sole person complaining about the additional header cell (despite it being valid according to MOS:TABLE, under "multi-column standard with subcolumns"). You are actively reverting a change that is allowed under the MOS, and for what reason? What purpose does you constantly reverting my changes serve other than to cause continuous deadlocks? - Evelyn Harthbrooke (leave a message · contributions) 07:44, 25 September 2024 (UTC)Reply

I never said that the extra header row goes against any policy, but it does create excessive header cells. The "Version" header can easily be put back into the OS name cells. May I remind you that you're the one who has consistently said these tables are "too long"? As for the captions, the tables don't show the "minimum and maximum supported version", they show all versions, it was factually incorrect. YannickFran (talk) 08:05, 25 September 2024 (UTC)Reply

There is no Wikipedia policy stating that "two header cells + two subheader cells" are excessive. - Evelyn Harthbrooke (leave a message · contributions) 08:57, 25 September 2024 (UTC)Reply

Again, where did I say there was? YannickFran (talk) 09:42, 25 September 2024 (UTC)Reply

You can't revert my edits then, as if my edits don't go against Wikipedia policy, there is no grounds to revert. - Evelyn Harthbrooke (leave a message · contributions) 12:00, 25 September 2024 (UTC)Reply

Also it wasn't factually incorrect. Minimum supported = version that shipped with a given device model. Maximum supported = Final version available on a given device. How is that difficult to grasp? - Evelyn Harthbrooke (leave a message · contributions) 08:59, 25 September 2024 (UTC)Reply

Sure, but that's not what the tables show, now is it? Words have meaning, "Minimum and maximum" implies that the table indicates the minimum and maximum version, but that's not what they do, they're an overview of all supported versions. That's the equivalent of changing the caption of the overview table to "Release dates of iOS versions" and calling it a day. YannickFran (talk) 09:47, 25 September 2024 (UTC)Reply

And they are redundant overviews that could very easily be condensed into Template:iOS versions while taking up significantly less space. - Evelyn Harthbrooke (leave a message · contributions) 12:01, 25 September 2024 (UTC)Reply

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)Reply

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)Reply

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

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)Reply

I just checked the readable prose size of this article, and its only at 26 kB (4502 words) "readable prose size", which means we have a significant amount of breathing room to expand the article quite heavily. And there are articles on Wikipedia that contain signfiicantly more words than this, such as Donald Trump at over 15,800 words (now that article could do with some heavy splitting). We're perfectly fine. - Evelyn Harthbrooke (leave a message · contributions) 10:43, 23 October 2024 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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

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

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)Reply

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)Reply

The navbar was removed from the header, and you still removed it. At this point I feel like you are actively criticizing and reverting any changes I make to the templates just for the sake of it. - Evelyn Harthbrooke (leave a message · contributions) 07:50, 25 September 2024 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

One more thing, the iPad template is especially cumbersome, due to all the rightward drift + downward drift for very little information. They are incredibly overly technical templates due to their overall complexity and the signfiicant drift necessary to adequately read the tables, and I still genuinely believe that having templates that are that complex are out of scope of what Wikipedia covers. - Evelyn Harthbrooke (leave a message · contributions) 06:48, 25 September 2024 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

This article is a list article, just like macOS version history. It really shouldn't have version histories at all. Completely disregarding that, why would the dedicated version article need to be more concise than the article that's trying to sum up everything? That makes 0 sense, and it clearly isn't being treated as such either since the iPhone OS 1 article actually has a history table with more details then the one on this page. It makes no sense to keep the same table twice in separate locations. Never mind that, according to you, we don't have any breathing room here at all. Unlike the table you restored, the other one at least was properly sourced, too. Consistency is not an issue and these tables can be moved out one by one, otherwise the fact that some versions to have histories and others don't seem inconsistent and we should remove them all together until every version can have its version history all at once. Section transclusion is a feature of Wikipedia for exactly this purpose. YannickFran (talk) 06:47, 25 September 2024 (UTC)Reply

It has always been a table-based article, and has always served the article well, for as long as I've been contributing and editing to the article. Also, saying it really shouldn't have version histories at all basically defeats the entire purpose of this article outright. I'm sorry but I am starting to find it really difficult to properly cooperate with you at this point, as every single conversation we have had, going as far back as May 2023, has always resulted in a continuous deadlock. We need to accept that we are never going to agree on how to handle this article or the templates. And for the record, I am in no way trying to not cooperate. But my opinion on this subject has remained pretty consistent, and so has yours. It's unlikely that this deadlock will end due to our heavily conflicting opinions. - Evelyn Harthbrooke (leave a message · contributions) 07:26, 25 September 2024 (UTC)Reply

Sure... and so where Windows 10 version history and Windows 11 version history until those articles became to large and they had their tables moved over to the main articles for each individual version. But again, you're latching on to an argument that isn't even relevant in this discussion. There is absolutely no reason to keep the same content twice, and despite arguing otherwise by you, the table on the iPhone OS 1 article clearly goes deeper into the history (and is actually properly sourced). You are turning reverting anything I do into a sport. YannickFran (talk) 08:18, 25 September 2024 (UTC)Reply

I have removed the version history tables for iOS 16, iOS 17, and iOS 18 from the article. These tables have been a breeding ground for basically copying verbatim Apple's release notes, despite the fact that the article was semi-protected to try and prevent this exact thing from happening, especially after the previous AfD nearly resulted in the entire article being deleted. Another reason I have removed the tables is because the sources used in them were sources incredibly close to the subject, such as MacRumors, AppleInsider, etc, despite there being a vast number of high-quality sources that focus on Apple/iOS while not being focused on that subject or only strictly covering the subject (as I do consider them to be primary sources under Wikipedia's sourcing guidelines instead of secondary sources which are more reliable). I spent today completely rewriting and expanding the iOS version history § iOS 7 section to both use high-quality sources and to detail the major changes and features added in the release. It is not that hard to find high-quality coverage about iOS, including on flagship news media such as CBS News, ABC News, and NBC News, or technology-focused news websites such as Ars Technica, The Verge, AnandTech, among others. This will allow the article to be entirely-prose based, while hopefully eventually improving to be somewhat high-quality, for what is essentially a list-based article, plus it will basically prevent editors from copying verbatim Apple's own release notes. The article will also hopefully no longer be at any risk of violating WP:NOTCHANGELOG, as the focus will not be to cover every single update released for each major iOS version, but to cover the significant updates that actually add new features instead of detailing every single update under the sun released for iOS including minor patch updates that only add security or bug fixes (see iOS version history § iPhone OS 1 and iOS version history § iPhone OS 2 to see what I mean, as those sections only cover the updates that actually add new stuff to the operating system).

Therefore, as the tables have been removed, I am requesting that they do not be re-added. Due to this change, it is very likely that the set of templates used for creating the tables (Template:iOS version table, Template:iOS version table/iOS version and its redirect Template:iOS version, as well as Template:iOS version separator) will be deleted, due to effectively being orphaned. I originally created those templates with the purpose of more easily creating the version tables, however it has come to my attention that these tables do not properly follow Wikipedia's MOS:TABLE guidelines or the guidelines surrounding the template namespace anyway, so its for the best that those templates be deleted.

Hopefully this explanation will allow readers and editors to understand why exactly I removed the tables, despite it likely causing some people to be disappointed. - Evelyn Harthbrooke (leave a message · contributions) 06:00, 14 October 2024 (UTC)Reply

The tables have been re-instated, until the applicable sections have been adequately rewritten in a prose format, in order to bring a somewhat resembleance of normalcy to this article, while the other sections are being rewritten in prose. - Evelyn Harthbrooke (leave a message · contributions) 23:44, 15 October 2024 (UTC)Reply

Could images be added to the sections under releases, to more visually identify and showcase what prior iOS versions looked like without having to go to the individual article, or would this fall out of the scope of fair use? As I feel like having images of each version would make for a more high-quality and more visual article. Especially for the longer sections that have been converted to be entirely prose-based, such as the sections for iPhone OS 1, 2, and iOS 7. - Evelyn Harthbrooke (leave a message · contributions) 22:09, 16 October 2024 (UTC)Reply

Context: A discussion on whether or not we should continue to use this format of tables as we use on various other articles as well (1, 2, 3, 4, 5, 6, etc.) over this format.

The tables have all been restored to their previous versions. This has been done for various reasons.

• First of, the fundamental reason with why the tables are in the format that they are in: as said many times before, presentation matters, it's why we don't write everything out in text. These tables' primary purpose has always been to provided a visual overview of the support, helping to both visualize how support expanded (and contracted) over the years, as well as the relative releases to one another. This was entirely lost.
• There is nothing wrong with how the tables are made in the first place. They are perfect accessible as they used to be. They are accessible for screen readers and people with reading disabilities. The changes made don't make the tables more "accessible for deaf or hard of hearing people", the matrix tables are exactly what one would use to accommodate such disabilities. Worse; people who are deaf and hard of hearing may prefer communication through ASL, in which case using written text over iconography is actually worse as many people in this group have difficulty with written language. This frankly comes across as a sick joke more than a (serious) argument. As for colorblind and blind people; that's what the iconography, and alt texts are for respectively.
  • If there are any actual concerns about whether or not the templates used in the tables are accessible, I suggest taking that up on the Template talk:Table cell templates page to discuss and further those improvements there and fix any concerns Wikipedia-wide (but frankly, these templates were made to accommodate all sorts of accessibility tools and issues, I really don't think there are any).
  • As for dark mode support, that sure is something that should be improved, but not an issue that must be solved by just stopping to use the relevant templates. When a fix is required, those should be implemented on Template:Ya and Template:Na (and any other relevant templates). There are already people having discussions and working on making these changes. Sure, it takes longer than anyone wishes for, but that doesn't mean we should now scour all of Wikipedia to remove the usage of these templates.
• These tables are commonplace on Wikipedia. The reason for that is, again, because they actually bring the point across very well, give a good visual overview, and already are accessible for those who cannot benefit from these visual representations. Just because some people cannot benefit from those visual representations doesn't mean we should rob everyone from them, especially not if that is detrimental to another group, and especially not if it is done in a way where they can still access the content perfectly fine through other methods and accessibility tools, that is what accessibility is about.
• Despite repeatedly claimed concern, the size of these tables is not an issue, and never was. The articles they are used in are far from their size limit (and would much sooner need to be split for their word count anyways). However, the merged n/a cells slash their size practically in half without sacrificing any valuable table borders that do help with accessibility.
• Further addressing repeated concerns: the tables are perfectly maintainable as they are. Adding a new device is a 1 minute copy-paste from the previous row, now with an adjust to the column span of the n/a cell and that's it. Adding a new iOS version is a 1 minute copy-paste job at the end of each row. It really isn't hard and if that really is a concern, just leave it for others to update, worst case scenario, add a request to update them. We've got a template exactly for that purpose.
• Given recent changes to both the overview table and version history tables, any concerns about duplication should be off the table, so not sure there is anything worthwhile to address there.
• Furthermore some minor points to raise about other changes made:
  • The reason devices like the first iPad Mini and iPad Air have a "(1st)" behind them is because that's how we do it everywhere when a device shares its name with its product line, e.g. "iPad Mini" and "iPad Air" are both the name of the product but also the product line, the generation notation makes sure that distinction is clear, just as we do with article titles.
  • Templates should probably be able to stand on their own, the changes made causes errors on pages where they are imported that didn't previously accommodate for a notelist. Disregarding that, having the notes under the relevant table is a common practice (as shown by the various tables mentioned above as well as many other tables across Wikipedia) and improves readability and usability. This is why the grouping options exist.
  • The repeated navbar on all iPad tables is useful to help people find their way to edit, talk and view the template. If a table doesn't have a navbar, the usual assumption is that they are part of the main article's source, which is not the case here.
  • The release date of a device isn't really relevant in the context of these tables (what version is supported on what device) and is not something that is done for tables like these. If there is a real need for this, they can be restored tho.

There have been repeated request to discuss such changes to those tables further up on this talk page. It would be incredibly great if those requests would be honored for a change instead of continuing to push through changes that have been discussed and reverted in the past (because yes, this approach too has also been tried in the past and has been shot down for being inadequate by others, sadly that discussion isn't on any existing article anymore). Preferably, any continued experimentation is done in a sandbox first if necessary instead of continuing disruptively editing articles and templates.

Finally, if there really is a concern about this table format, than that should be raised in a discussion and/or RfC and notifying editors on the articles mentioned above (and others that share similarly formatted tables) and WP:APPLE on whether such tables should continued to be used. YannickFran (talk) 10:49, 18 October 2024 (UTC)Reply

These templates, in the format that they were in before, have absolutely zero good information, as only having the major version alone is not the slightest bit helpful, and the template overall is hard as hell to read, not to mention downright doesn’t work properly on mobile due to contrast and readability issues. Additionally, the grouping behaviour of the note list template does not work. It causes issues with any other note list call, which is why I removed them in the first place, they downright break MediaWiki behaviour and prevented the existence of a dedicated novelist. Trust me, I tried. Due to the other notelist calls, it overrode the bottom novelist. The article in question that broke should just add a notelist template. Having notelists in tables is bad, as it disallows the use of a central notelist, and last I checked, I made that change after another editor did it for the iPod touch table, so you have two editors against you on that one.

These templates have no reason to be as visual as they were, they again provided zero useful information other than "this device supports x major version and x initial version, but sorry you don't get to know the specific version" There was a significant number of issues with the previously implemented template, in that they provided zero benefit and were overly visual, they were bad for accessibility (because of the fact that a) they broke on mobile and b) being overly visual doesn't help people who are blind to begin with, not to mention takes accessibility screen readers such as VoiceOver a significant amount more time to get through the template, time people likely just don't have to sit through an hour of VoiceOver reading a table). Your excuse that people speak in ASL is not a valid reason to revert the template changes I made either as ASL isn't a digital language, it's a physical language that usually requires the use of a an ASL translator as web pages can't speak ASL. And again: there does not need to be redundant cells for every single iOS version in existence. There is no rhyme nor reason that could actually properly argue for the templates to be as overly visual as they are, they are both visually overwhelming and unnecessarily complicated for no real reason, not to mention that cause fatigue and visual overstimulation for people with e.g. autism (I am personally autistic and find the templates in their prior implementation visually overwhelming and overstimulating visually, however it could differ fom person to person, but still)

And for the record, my changes don't increase the time it takes to add a device: Copy/paste a cell, update the device's name to reflect the latest model, and you're done. Or for a device that has support ended, replace the Current iOS template with the last supported version or replace it with the dedicated iOS x template if necessary. There was no consensus held on the tables to keep them in their X/checkmark format, and I actually checked the edit history for the iPhone template in full on this one, this has actually never been attempted. And the potential RFC on the tables were never even held; the discussion died before anything happened. All of these conversations have been quite frankly one sided, with them always being in dead lock because it is ALWAYS only you and me in disagreement. That is why I find it useless to hold conversations on a talk page when it comes to these templates, because the conversation will likely end up one-sided, or deadlocked. I have restored my version of the templates due to these reasons. - Evelyn Harthbrooke (leave a message · contributions) 19:46, 18 October 2024 (UTC)Reply

Also, Yannick, just because a table format is commonly used across Wikipedia does not mean that it will work well for every single scenario. And in this case, they do not. - Evelyn Harthbrooke (leave a message · contributions) 19:52, 18 October 2024 (UTC)Reply

• These templates, in the format that they were in before, have absolutely zero good information, as only having the major version alone is not the slightest bit helpful - This lacks any argument and is not what these tables try to convey in the first place.
• and the template overall is hard as hell to read, not to mention downright doesn’t work properly on mobile due to contrast and readability issues. - This is just false... There is nothing wrong with these tables on mobile "due to contrast", never mind readability. Again, any issues with the templates (which I cannot help but notice you still haven't actually mentioned which you are concerned about) should be solved there. Lacking support for dark mode - an ongoing effort - is not a reason.
• It causes issues with any other note list call, which is why I removed them in the first place, they downright break MediaWiki behaviour and prevented the existence of a dedicated novelist. Trust me, I tried. Due to the other notelist calls, it overrode the bottom novelist. - Yeah no, that's just not how notelists work. Grouped and none-grouped note lists can co-exist on one article perfectly fine.
• There was a significant number of issues with the previously implemented template, in that they provided zero benefit and were overly visual - No, they are not. I know you think they are "an eyesore", but that is both completely subjective and isn't a reason to remove anything.
• they were bad for accessibility (because of the fact that a) they broke on mobile and b) being overly visual doesn't help people who are blind to begin with, not to mention takes accessibility screen readers such as VoiceOver a significant amount more time to get through the template - When you started talking about accessibility the first time around, you didn't even bother to check if the Yes/No templates provided alt texts and just claimed they were bad for screen readers. The fact that you're now going with "being overly visual doesn't help people who are blind to begin with" is frankly downright insulting and completely besides the point. I don't get where you keep pulling such statements from. It's painfully clear that you don't know what you're talking about in regards to accessibility (again, you couldn't even bother to check for alt text the first time around, then pretended header cells and captions were the same thing, then refused to follow the MOS and accessibility policies because "they can be ignored", then argue that a table isn't accessible for deaf people and hard of hearing people).
  • Also "they broke on mobile"? How exactly? They are just tables. If that breaks something, then so does the tables as you try to make them.
• time people likely just don't have to sit through an hour of VoiceOver reading a table - What are you even trying to argue here? People who use screen readers know how to efficiently navigate with screen readers. We've got an entire category dedicated to articles with tables like this.
• Your excuse that people speak in ASL is not a valid reason to revert the template changes I made either as ASL isn't a digital language, it's a physical language that usually requires the use of a an ASL translator as web pages can't speak ASL. - That wasn't an excuse I made, you're the one who brought it up, I counted your argument. Unless you were referring to any other kind of deaf or hard hearing aid that may be relevant to reading comprehension where text is preferred over visuals? Also, it not being a digital language is completely besides the point. Fact is that people that do communicate mostly though sign languages in general have a harder time with written text. For those people, iconography and the use of color is preferred.
• There is no rhyme nor reason that could actually properly argue for the templates to be as overly visual as they are, they are both visually overwhelming and unnecessarily complicated for no real reason, - There is, they were listed above. They provide a great visual overview of the evolution over models and versions, they are very much accessible, they are concise and quick to scan through. You refusing to acknowledge them doesn't change that, because nothing of what you said actually goes against any of these reasons provided. You just go on again on how these tables aren't accessible despite having been told, multiple times by multiple people, that they are. Accessibility is part of my job, I do know what I'm talking about.
• not to mention that cause fatigue and visual overstimulation for people with e.g. autism (I am personally autistic and find the templates in their prior implementation visually overwhelming and overstimulating visually, however it could differ fom person to person, but still) - I'm sorry to hear that and also; welcome to the club. If this is an issue for you, I can highly recommend the use of accessibility tools that help reduce over-stimulation like screen filters. There are plenty more tools out there to help with this among which are various browser plugins to deal specifically with the web, but macOS has a vast array of features built-in too (as has any major OS). Having said that, if even pastel colors are triggers for you, I'm not sure why you aren't using such assistive technologies already because that just sounds like you are torturing yourself. If this was your issue, I'm frankly not sure why you kept calling them an "eyesore" without ever making the nuance that that's what that comment was about. I get it, not everyone likes to parade with "I've got autism", but you could have just said "people with autism may have issues with this" in which case I would have mentioned such tools without ever knowing you were talking about yourself.
• And for the record, my changes don't increase the time it takes to add a device - ...okay? I never said it did.
• and I actually checked the edit history for the iPhone template in full on this one, this has actually never been attempted - ...Which is why I said "sadly that discussion isn't on any existing article anymore". The articles this was done on have since been removed. Having said that, you've repeatedly claimed my references to previous conversations where "made up" despite me providing you with links to them. I really don't feel like scouring the Web Archive for this, but be sure you can take my word on this: it has been discussed before.
• Also, Yannick, just because a table format is commonly used across Wikipedia does not mean that it will work well for every single scenario. And in this case, they do not - The provided scenarios are literally the exact same type of table for the exact same purpose.
• All of these conversations have been quite frankly one sided, with them always being in dead lock because it is ALWAYS only you and me in disagreement. - No it hasn't. It has always been you and then a couple of other people (coming in naturally or through 3O) in disagreement. You just keep pretending they aren't there. It's always your way or the highway. There have been a bunch of compromises from my side already. And every once in a while after I published such a compromise, you'll revert to your way then re-revert back to the compromise at which point I think "ooh, we've finally reached something we can both agree on", only for you to then double down even further later. You haven't compromised - or showed any willingness to do so - even once. I agree that's no way to hold a conversation, but you're in no position to blame that on me. Every time you're given a hand, you demand an arm.

Anyways, you're edit summaries make clear you are completely unwilling to discuss, which is weird because earlier this week you said you are "completely and fully open to having a discussion, but only if it won't escalate into hostilities and attacks", to then follow that up with "I am done having one sided conversations" seems kinda disingenuous. I'll be asking for extra opinions from the Apple WikiProject. If that doesn't help out, we'll continue on with an RfC to solve this. YannickFran (talk) 21:36, 18 October 2024 (UTC)Reply

Yeah no, that's just not how notelists work. Grouped and none-grouped note lists can co-exist on one article perfectly fine. I tried adding a dedicated note list section in numerous of my other edits, I had to self revert because they just wouldn't show up., maybe because the note lists used in the templates weren't actually being assigned the right group, but still.

The provided scenarios are literally the exact same type of table for the exact same purpose. No? It gives one example, of how to handle color, not about how to handle every single table in existence. Some tables are better visually, others are better off as text. I feel that these templates are better off as text because they're more easily processable that way for the vast majority of people.

make clear you are completely unwilling to discuss, which is weird because earlier this week you said you are "completely and fully open to having a discussion, but only if it won't escalate into hostilities and attacks", to then follow that up with "I am done having one sided conversations" seems kinda disingenuous I am willing to discuss, but with more than one person as me and you have always resulted in a deadlock. Has nothing to do with me being unwilling to have conversations. I firmly believe that my approach is better, because it's a lot simpler. Tables don't have to be overly complicated, especially when at the end of the day the templates purpose is to convey "what device supports what iOS version". If that's all the template is trying to convey, it would be better served by showing the device's initial version, and its latest compatible version (and as Apple releases security updates at times to older iOS versions that newer devices don't run, this is actually quite helpful) rather than just shoving each major iOS version in a cell and calling it a day. It also doesn't require unnecessary "iPhone OS" and "iOS version" headers. - Evelyn Harthbrooke (leave a message · contributions) 21:58, 18 October 2024 (UTC)Reply

I tried adding a dedicated note list section in numerous of my other edits - Well, I don't know what you did to run into that issue, but see Template:Notelist#TemplateData for documentation on that.

No? It gives one example, of how to handle color, not about how to handle every single table in existence. - There are 6 examples given of the exact same type of table, they are again quoted in the line at the top of the conversation. I'm not sure how you can argue that they aren't.

especially when at the end of the day the templates purpose is to convey "what device supports what iOS version" - I feel like you continue to ignore that a) that's not their only purpose, and b) presentation matters.

I am willing to discuss, but with more than one person as me and you have always resulted in a deadlock. - It always results in a deadlock because you refuse to compromise and constantly contradict yourself. For example, you spend a lot of time at the start of this discussion claiming that because the "tables were gone for months" that that's the status quo that should be maintained, despite that not being true. Now you demand your version to stay despite it not being the status quo. Or in this edit (which, by the way, incredibly ironic that you're there admitting that in your opinion there is no accessibility issue with how the template was) you're pretending templates shouldn't have more then 1 table, only to immediately flip-flop on that in the next edit. You've repeatedly invented policies and guidelines, ignored actual policies and guidelines, refused to follow consensus, claimed the MOS and Accessibility policies aren't enforceable, quoted general policies without elaborating on what the issue actually is, and misinterpreted various other policies. It's indeed very hard to argue when that keeps happening over and over again. And in general refused to actually elaborate on previous claims you've made. E.g. you still haven't said how the tables are broken on mobile (or acknowledged any of the actual content-related points made). YannickFran (talk) 10:09, 19 October 2024 (UTC)Reply

Like I said: I have no idea what exactly caused the notelists to bug out when I tried adding a new notelist, all I know is that because of the number of notelists already on the page, when I created a dedicated notelist section, and tried adding a note, the note went into one of the table notelists. Also, I am by no means perfect, I can contradict myself as much as I need to if I later realize that something I have done needs improvement, or can be done in a different way. And I already explained how they're broken on mobile, Wikipedia on mobile is not built with complex tables in mind, let alone for tables with a billion {{ya}}, {{na}} and {{n/a}} templates, especially not when it comes to dark mode.

And what other purpose could the template(s) possibly serve? Because as far as I could tell, its only purpose is to convey whether or not x device supports x iOS version, which does not need to be a convoluted table. Just say what version a device shipped with and its final compatible version. It doesn't need to be visually stimulating and technically complicated just to get a point across. People at the end of the day, when looking at these templates, only wanna know if a device is out of support. It's easy to give that information by text. It doesn't need to be a billion checkboxes.

And I can raise numerous issues with the other templates that use the checkbox table style, such as the table on MacBook Pro, which is so overly visually complicated that it requires literal scrolling to be able to process all of its information and also goes literally outside of the borders of Wikipedia's own Vector skin. How is that beneficial? (although that could be solved by moving the versions to the top and moving the models to the side; while it would increase vertical space it wouldn't be as wide, because I do agree that the format of that specific table is better. It should also be noted that it is my view that Wikipedia should not be encouraging, or even advertising, the fact that Apple's EOL for its devices can be bypassed by using unofficial patches and tools that could potentially brick a user's old machine or make them unstable or significantly slow, especially if they don't know what they're doing, but that specific complaint is out of the scope of this specific article.

And I was not pretending. The goal by splitting them into multiple was to be able to easily move them over to separate template pages in template space, which I did, both to allow more modularity, and easier maintaining of the tables. The reason I mentioned the one table thing is because I don't usually see a template do more than one thing, so I thought it might've been Wikipedia policy to not. If it wasn't, then I accept that I was wrong to assume that. But it still arguably makes a specific template more convoluted when you're working with more than just one thing, it's why the whole phrase "do one thing and do it well" exists, as something should typically do one thing, and do it well.

My point with all this is that there are easier ways to do something, you don't have to make something incredibly over engineered when it doesn't need to be. Things should be simple whenever possible, it's why I prefer iOS as an OS instead of Android, due to its simplicity as it doesn't make things overly complicated for the end user and is easy enough to use to where almost anyone could figure out how to use it. Nothing I am ever trying to do at any point is to go against Wikipedia's MoS or policy guidelines, ever. It should also be said, by the way, that there is no status quo in place for those templates with regard to their overall behaviour. There is the status quo of allowing the tables to live on the article, but not about how they should look; I'll respect that status quo but there is no status quo to respect with regard to their visual behaviour. Anyways I'll follow up on this when I wake up. I am exhausted and need to sleep. - Evelyn Harthbrooke (leave a message · contributions) 12:39, 19 October 2024 (UTC)Reply

And I already explained how they're broken on mobile, Wikipedia on mobile is not built with complex tables in mind, let alone for tables with a billion ya, na and n/a templates, especially not when it comes to dark mode. Note how you are in fact not explaining what is broken. "Wikipedia on mobile is not built with complex tables in mind" is just... false. a) Wikipedia on mobile is very much capable of as complex of a table as Wikipedia on the web, and b) these tables aren't complex. If they are, then every table is. That templates don't support dark mode is something that should be solved with the templates, not the content, and it isn't a reason not to use the templates.

And what other purpose could the template(s) possibly serve? - To visualize and properly show a progression in how support for devices expanded and contracted over the years. This was completely lost. This has been said before. Ignoring it doesn't change that.

And I can raise numerous issues with the other templates that use the checkbox table style, such as the table on MacBook Pro, which is so overly visually complicated that it requires literal scrolling to be able to process all of its information and also goes literally outside of the borders of Wikipedia's own Vector skin. - Are you seriously trying to make the argument that a table that can only be seen in full by scrolling is an issue? Seriously? Because not only does that apply to a vast number of tables on Wikipedia (especially on mobile), but Wikipedia also provides tools to make that work just fine.

while it would increase vertical space it wouldn't be as wide, because I do agree that the format of that specific table is better - Frankly I'm confused, because this inverted-axis format is exactly the format the tables on this page have.

It should also be noted that it is my view that Wikipedia should not be encouraging, or even advertising, the fact that Apple's EOL for its devices can be bypassed by using unofficial patches and tools that could potentially brick a user's old machine or make them unstable or significantly slow, especially if they don't know what they're doing, but that specific complaint is out of the scope of this specific article. - Out of scope indeed, but just to point it out; it isn't Wikipedia's place to tell users what they can and cannot do. If the tool exist and it is notable, it gets documented on Wikipedia. People thought it notable, so there it is.

I thought it might've been Wikipedia policy to not. If it wasn't, then I accept that I was wrong to assume that. - And you didn't look it up because...? This isn't the first time either... For the record, that is a rhetorical question, because it's completely besides what is actually being discussed here: the content.

My point with all this is that there are easier ways to do something, you don't have to make something incredibly over engineered when it doesn't need to be. - A yes/no comparison table isn't "over engineerd", again Wikipedia has an entire category dedicated to articles with such tables.

Nothing I am ever trying to do at any point is to go against Wikipedia's MoS or policy guidelines, ever. - Who is this bit for? You've literally argued that policies and MoS don't apply because you didn't like them, so we know this is a lie.

There is the status quo of allowing the tables to live on the article, but not about how they should look; I'll respect that status quo but there is no status quo to respect with regard to their visual behaviour. - And this is the problem. You keep cherry-picking rules and policies to apply only when you believe it benefits your position. And when they don't, you either change what they mean as you're doing right here her pretend they can be ignored. Because you do know what the words "status quo" mean, right? They mean "existing status of affairs". This is the status quo (per WP:QUO, the tables as they used to be, that is the status quo, the thing you were so eagerly trying to maintain the first time around. It's a status quo I've repeatedly tried to discuss and compromise on with you (per WP:BRD). You haven't done a thing other than to demand discussions, only to then refuse to discuss anything, just to keep doubling down further and further every time I tried to find a compromise. YannickFran (talk) 18:39, 20 October 2024 (UTC)Reply

Note how you are in fact not explaining what is broken. "Wikipedia on mobile is not built with complex tables in mind" is just... false. a) Wikipedia on mobile is very much capable of as complex of a table as Wikipedia on the web, and b) these tables aren't complex. If they are, then every table is. That templates don't support dark mode is something that should be solved with the templates, not the content, and it isn't a reason not to use the templates. No it is not, Wikimedia themselves have said that the mobile app on Android and iOS doesn't have as robust of support for tables and other content that the desktop site does, and there are some cases where tables and templates are outright unsupported on mobile, such as in the case of navboxes and other navigation aids and other templates where they have a "This template is unsupported on mobile" warning when you go to its Template page. So no, Wikipedia's mobile app is indeed not built with all kinds of tables in mind, not to mention is an overall buggy app in my experience to where I just resort to the website anyways, a) because its a lot easier to read and b) it supports everything supported by MediaWiki, which cannot be said for Wikipedia's mobile app.

To visualize and properly show a progression in how support for devices expanded and contracted over the years. This was completely lost. This has been said before. Ignoring it doesn't change that. I am not ignoring it, it's just unnecessary. There has been zero contraction of support, each iOS device gets about 5-7 years of support, aside from in the beginning where devices got around 3 years of support. And it's very clearly obvious that going from iPhone OS 1.0 to 3.1.3 is three major iOS versions of support. There is no reason for the tables to be in a yes/no format especially if it compromises on information. And arguably, the templates don't need to be in a yes/no format because of that.

Are you seriously trying to make the argument that a table that can only be seen in full by scrolling is an issue? Seriously? Because not only does that apply to a vast number of tables on Wikipedia (especially on mobile), but Wikipedia also provides tools to make that work just fine. No, only when they are so long to where they go past the page and cause the entire page to scroll with it to the point of other content going off screen.

A yes/no comparison table isn't "over engineerd", again Wikipedia has an entire category dedicated to articles with such tables. In this specific case, yes it is. It does not need to use yes/no templates to get its point across, at all.

And you didn't look it up because...? This isn't the first time either... For the record, that is a rhetorical question, because it's completely besides what is actually being discussed here: the content. I can't look up every single Wikipedia policy or guideline in existence. I go with my gut feeling, in terms of what might be allowed vs what isn't, however I have been reading the MoS more often to ensure that my edits are higher quality than they have been in the past. From what I see however, Wikipedia's template policies aren't as robust as the main Manual of Style, as in my opinion there should be a policy in place to only allow templates to have one table, rather than multiple, and if multiple tables have to exist for whatever reason, that they should be split, a) to allow easier maintainability and b) to allow better integration with wikitext.

Who is this bit for? You've literally argued that policies and MoS don't apply because you didn't like them, so we know this is a lie. Now that is an actual lie, because no it is not. I have never once said that Wikipedia policies and the Manual of Style don't apply because "I don't like them." Period. I like the Manual of Style, and I agree with Wikipedia's policies in the vast 99% of cases. The only point I was trying to make is that if a Wikipedia policy prevents a piece of content (such as a template or article) from being improved, that is why WP:IGNORE exists, which is why I said that they aren't always enforceable in a prior conversation, due to that policy. I was never once trying to say that I don't like the policies or that they are never enforceable, at all.

You keep mentioning Wikipedia's policies, yet you seem to barely follow them yourself, specifically when it comes to interactions with other editors. You have resorted to numerous personal attacks (WP:NOPA) toward me, including calling me a liar and responding with snarky remarks such as Are you serious?, both more than once, as well as the numerous other times you have attacked me in previous conversations. Now I'm not denying that I have been as well but I apologized for them and also stopped with them, even though I should have never responded with them in the first place. You are continuing, however, to attack me. Over the way tables on a page look. The point of tables in my view is to get critical information as quickly as possible; that is why tables are so ubiquitous and common across the entire Internet, because they are intended to be quick sources of information that a user can process quickly. And in my view, the yes/no format just doesn't do that properly in the case of this specific article due to the amount of complexity they require, as well as the number of tables that are present. There is no policy or guideline in place that enforces or requires Apple-related articles to conform to the same table format. I'm going to be brutally honest and say that the majority of our conversations have left a sour taste in my mouth to where I am seriously considering ceasing further discussion with you as an editor in specific, because I am not going to sit here and take your personal attacks any longer, for the sake of my own mental health. Advice for you, please read Wikipedia's essays on civility and take them into consideration before you reply in the future, as I likely won't reply if you come back with a snarky remark directed at me again. It just won't be worth it. - Evelyn Harthbrooke (leave a message · contributions) 21:30, 20 October 2024 (UTC)Reply

You keep mentioning Wikipedia's policies, yet you seem to barely follow them yourself, specifically when it comes to interactions with other editors. You have resorted to numerous personal attacks - Sigh... Pointing out you constantly contradict your own actions (including demanding the status quo to be retained in the first discussion and now pretending your new edit is the status quo) isn't a personal attack. Telling you that something you said (trying to imply) is a Wikipedia policy when it isn't is pointing out a lie, yes, but it isn't a personal attack. Asking "Are you serious?" is not a personal attack. You know what is tho? Going out of your way to call people toxic and disruptive. I haven't once made an actual personal attack against you. Furthermore, "It should be noted that I am completely and fully open to having a discussion, but only if it won't escalate into hostilities and attacks" clearly wasn't true either. You can't possible argue there was hostility or "attacks" when this discussion started (or even at this point), but you immediately slammed the door the a conversation you requested.

I can't look up every single Wikipedia policy or guideline in existence. I go with my gut feeling, in terms of what might be allowed vs what isn't - Then just don't say it or look it up. It's 1 thing to check, nobody is asking you to read all policies. Wikipedia policies aren't a "gut feeling". You don't get to run around claiming (or at the very least implying) something isn't allowed when that's just your personal opinion. You don't get to make up your own rules, and then expect other editors to just guess at whatever those are until someone points out that it is in fact not a rule.

Regardless lets talk only content from here on out.

No it is not, Wikimedia themselves have said that the mobile app on Android and iOS doesn't have as robust of support for tables and other content that the desktop site does, and there are some cases where tables and templates are outright unsupported on mobile, such as in the case of navboxes and other navigation aids and other templates where they have a "This template is unsupported on mobile" warning when you go to its Template page. - Please link to documentation where these issues are discussed as being present today and applicable to these tables (in general, please link to policies/guidelines/bug reports you quote/mention). The only way tables aren't supported according to the current documentation (both on MediaWiki and Wikipedia) as far as I can find is if they are used to create page structures (which hasn't been allowed for a long time) and the align property (may) get ignored on mobile. Every other thing you mention doesn't actually apply to these tables (they aren't navboxes, they aren't navigation aids, they aren't complex, and they did work on mobile). These are all issues that do not apply to this use case. The overflow issue is something that can be fixed with a simple class. You still haven't said how these tables are "broken". This is just gesturing to general concepts without elaborating how they apply to this situation. What specifically is broken about these tables?

I am not ignoring it, it's just unnecessary. There has been zero contraction of support, each iOS device gets about 5-7 years of support - "There has been zero contraction of support" is false and "each iOS device gets about 5-7 years of support" is a contradicting statement to the first, showcased by the fact you had to use a range and not say "it went from 3 to 5 to 7". For the iPhone for example it want from 3 to 4 to 5 to 4 to 6 to 5 to 7 to 6 back to 7. The various iPad lines and iPod Touch have seen similar (and sometimes even more extreme) fluctuations. So this statement is clearly false. That fluctuation is an important data point, and one that benefits from being visualized. Ironically it could even have prevented you from making this false claim in the first place. It's why every other article uses this format.

I suggest we make this one part of that 99% and continue to follow WP:BRD, building on top of the tables as they are per WP:QUO but addressing your concerns by including the merged n/a cell, applying the overflow fix, and for now the individual notelists until it's figured out why that breaks (I'll make an attempt at cracking this later). I suggest we retain this modified version of the actual WP:QUO until this discussion is solved. As I've requested discussion on WP:APPLE on the 18th, I propose to wait until the 25th to make an RfC if no other participants join in the discussion or no conclusion can be reached before then, a week of time feels like its long enough. If you feel an RfC should be opened sooner, I'm open to that too. If you feel like other resolution options should be invoked in the mean time (e.g. WP:3O) then please do so. Of course any constructive edits that aren't plain reverts and actually attempts to work towards a solution are very much welcome, but I strongly suggest to at least have these reasons articulated and grounded in actual policy, guidelines or something that at the very least is an actionable concern with elaboration (and not "tables are broken on mobile").

There is no rhyme or reason to hold an RFC on the appearance of how tables appear on a Wikipedia article; there is no "Apple Manual of Style" on how tables should appear; there is also no status quo on these tables, as these tables have been constantly changed and/or modified since their addition. The tables in their old form were overly technical, required a lot of repetition just to add a new column/row (whereas the current tables make significant use of the Template:Current iOS/short template and only require the addition of a new iPhone model row which makes things pretty easy to keep up to date), and significantly harder to scan quickly. I hold my ground that the tables do not need to be that complicated. They hold no benefit over the new tables. And the fact that you seemed fit to once again revert my edits despite me firmly disagreeing on the old tables was downright inappropriate. There is no Wikipedia policy that states nothing should ever be changed, everything should stay the same. The old templates only served to be pretty; they had no functional purpose despite your arguments. People look at those tables to see the minimum and maximum iOS version supported by a device, not to see how many versions of iOS a device doesn't support, which is my main argument: Tables are, again, meant to be quick sources of information that users can read really quickly. Nobody wants to scan 18, 19, or even 25 columns (come iOS 25) to see the maximum version of iOS a device is compatible with. That is precisely why I've been arguing over and over again that these tables were quite frankly over complicated in their previous implementation, and why I can't in good conscience agree with going back to them. And based on the fact that nobody else has participated in the discussion, I am getting the vibe that nobody is really interested in arguing over how a template looks. They have better ways to spend their time instead of arguing over a few insignificant templates that don't really impact the article in any meaningful way; the only impact these templates have had is causing a significant divide between two editors who can't agree on a damn thing. This is quite frankly beating a dead horse at this point, which is why I have decided to back out of this discussion. You are the only one who has disagreed with the table format, and quite frankly I have no idea why you care so much about the behavior of these templates. At the end of the day, they're just tables. Not every single Wikipedia article related to Apple has to have the same format of table, if it did there would surely be a Manual of Style under the Apple WikiProject that would define how articles related to Apple should behave, however the WikiProject has significantly died down, there isn't anywhere near as much activity as there used to be, and there is no MOS specific to Apple articles. - Evelyn Harthbrooke (leave a message · contributions) 09:40, 23 October 2024 (UTC)Reply

RfC's are exactly to discuss things that aren't explicitly stated in policies or guidelines. As for what is the "status quo"; yes there is. These tables have been like that for years. That is the "status quo". You can't keep saying that I revert your edits when you "firmly disagree" with that when a) I'm the one actually trying to incorporate your feedback into them and b) you yourself reverting without even bothering to work towards an agreeable version. I can say the same thing about you, and be more justified in that position. The old templates didn't "serve to be pretty", visualizing a data point has value (and one that you misrepresented in this discussion no less). Not only that, but you keep ignoring questions; what was broken about these tables? This is the problem, you keep bringing up issues, but when I asked to elaborate on what exactly the problem is or give feedback that is actually actionable, you just ignore it and move on to the next issue. This is quite frankly beating a dead horse at this point. You are the only one who has disagreed with the table format, and quite frankly I have no idea why you care so much about the behavior of these templates. At the end of the day, they're just tables.

I'm asking you to self-revert your changes or at the very least try to compromise here, because while you have repeatedly thrown around that my edits have been "disruptive" despite incorporating some of your feedback, yours actually are. YannickFran (talk) 12:06, 23 October 2024 (UTC)Reply

The tables have been around barely over two years, so no, they haven't been like that for years. And your changes that incorporate my feedback are still keeping the old convoluted table format including its significant downsides and flaws of the pre-existing templates. The previous templates I'd argue violate WP:INDISCRIMINATE, and the new format might still violate it. The goal of Wikipedia is to be an encyclopedia, which means that everything included in said encyclopedia should and must be fully and properly sourced. These tables are not, which mean they also likely fail WP:DUE. Wikipedia is also not a database. Version history articles are meant to be an encyclopedic entry on an operating system's development and history, not to be a database consisting of what iOS model is compatible with what versions. There are far superior places on the Internet to get information like this which is why I still disagree with their existence on this page. I would revert my changes if I actually had a valid reason to, but I don't, as I do still firmly believe that my changes make the template better. Again: The tables now show the intial iOS version and its exact maximum version, not just a major version that literally provides no helpful information. And wow. Imagine using my own words against me. You are the one who started this whole entire conversation when you originally reverted my changes. You seem to want to contest and debate every single change made to these tables unless they fit within the old format, when the old format is one I vehemently disagree with due to their unnecessary complexity. There is no world in which I can make a compromise with the old yes/no format. I just can't. It's a bad format for tables like this. - Evelyn Harthbrooke (leave a message · contributions) 12:34, 23 October 2024 (UTC)Reply

The tables have existed for years one way or another, they were only moved to this article about 2 years ago. You know this. We've been over this. But even disregarding that, even if they were only here for 2 years, that's still the status quo. And again, please elaborate when you claim certain policies apply instead of vaguely gesturing to them, especially if you're just going with completely different issues again, because how exactly does WP:INDISCRIMINATE apply in this scenario? It isn't a summary of a work, it isn't a lyric, it isn't an unexplained statistic and it isn't a log. Or how does WP:DUE even remotely apply? There isn't a minority or majority opinion in what version of iOS runs on what device. What we do have is precedence that these tables are in fact fine. If you want sources to be added, that is something that can simply be solved by doing so (or requesting it to be done) instead of blindly reverting changes. Anyways, thank you for confirming you were never actually planning to have an actual discussion. YannickFran (talk) 13:23, 23 October 2024 (UTC)Reply

If we're going off a so called status quo, from 2008 up until October 20, 2022, this article had no such templates until someone decided to add them, despite them not providing any overall benefits or adding any significant substance to the article as a whole; it provides no significant level of information whatsoever that relates to the development history of iOS as an operating system; they belong on the device-specific articles under an "Operating system support" section or something, akin to MacBook Pro (Apple silicon). They do not belong here. And this was an actual conversation, you just disagree with literally everything that touches the templates in any significant or meaningful way. It has honestly come off throughout these conversations as you acting like you WP:OWN the templates, while I have barely touched them other than to simplify them and make them less complex and to split them off into different templates for the different iPad models. I have tried at every possible juncture to cooperate with you, I have given a billion reasons behind my line of thinking and reasoning for making the changes I have to the templates. But quite frankly it makes it impossible to do anything when I have a fellow editor reverting any significant changes made to the templates. - Evelyn Harthbrooke (leave a message · contributions) 14:05, 23 October 2024 (UTC)Reply

I am growing tired of this constant back and forth. I have given numerous reasons why these tables belong on their device specific articles and not here. They provide absolutely no usefulness whatsoever to the overall substance and significance of the article as a whole, nor do they relate to the development or version history of iOS at all. It'd be like having a table on Android version history for every single Android device ever made and its supported Android versions, despite it not having any relation whatsoever to its development. Yet you refuse to listen to anything I say. Why is that I have no issues with any other editor, yet you and I always and constantly butt heads? - Evelyn Harthbrooke (leave a message · contributions) 22:43, 24 October 2024 (UTC)Reply