This article is within the scope ofWikiProject Lists, an attempt to structure and organize alllist pages on Wikipedia. If you wish to help, please visit theproject page, where you can join the project and/or contribute to thediscussion.ListsWikipedia:WikiProject ListsTemplate:WikiProject ListsList
This article is within the scope ofWikiProject Apple Inc., a collaborative effort to improve the coverage ofApple,Mac,iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc.
This article is within the scope ofWikiProject Brands, a collaborative effort to improve the coverage ofbrands on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.BrandsWikipedia:WikiProject BrandsTemplate:WikiProject BrandsBrands
List of iPhone models (final version) received apeer review by Wikipedia editors, which wasarchived on 23 June 2024. It may contain ideas you can use to improve this article.
Removing the obsolete/vintage/unsupported distinction
Decided to beBOLD. My latest edit removes the distinction being made between a device being obsolete, vintage and unsupported and instead opts to call these devices "unsupported". These data points previously relied on a definition given by Apple, which we here. However, Apple's seemingly arbitrary way of assigning these designations to devices has only led to us having to make notes explaining away why a device that shouldn't be vintage yet is, why a devices that should have been marked obsolete long ago isn't, and why a specific color or storage size of a device is marked vintage or obsolete and no other model is. Of the 10 notes on this page, 9 are dedicated to fixing this (and leaving more discrepancies unexplained).
For this reason, I've removed the distinction and recolored the "Discontinued and unsupported" color in the legend to match the default table heading color so whenever a device reaches this status, we simply can remove the styling (and Wikipedia's dark mode is happy too). This edit also removes the latest iOS coloring and the coloring of the "Discontinued date" and "Unsupported date" rows in the comparison tables as this is simply redundant and just more to maintain/overlook.YannickFran (talk)19:22, 3 January 2025 (UTC)[reply]
I concur. The obsolete and vintage categories concern repairs and hardware support more than article standards, not to mention what Stephen"Zap" said.Cnscrptr (talk)18:25, 7 February 2025 (UTC)[reply]
Whether or not I'll spend time actually implementing it is a bridge to cross later, but I'd rather do it without being reverted.
Right now, the article splits the comparison tables between "Unsupported 32 bit", "Unsupported 64 bit from 2013-2017", "Supported without Apple Intelligence" and "Supported with Apple Intelligence". We're dividing devices based on a rather arbitrary change in their capability that is bound to result eventually in one side of the split being much larger than the other (both for the 32 bit and for the Apple Intelligence splits). All in all, the move to 32 bit isn't that notable and seems mostly picked because at the time, it divided the table roughly in 2, but that is no longer the case.
Having devices move from one table to the next just because a certain date passes also seems a bit to arbitrary, especially since we don't actually know when Apple stops providing support for an older version of iOS (currently the tables assume if it isn't the latest major it is unsupported, but that isn't really the case).
So I propose we need to divide these devices differently. One possibility is to divide by generation (e.g.Comparison of Samsung Galaxy S smartphones), an issue with that is that for pre-iPhone X generations, we'd probably want to combine multiple.
However, the way I think makes the most sense is to simply split by premium, regular and entry level similar to how the timeline at the bottom does it. It makes more sense to me to compare the various SE devices with one another, and the various Pro devices, rather than having the tables flip-flop between the type of device that is being compared. Further more, given the lack of differences between a base model and its Plus/Max variant, it might just make more sense to combine them and denote any difference if they are applicable. For the vast majority, this is only relevant for device sizes, the only exception being the iPhone 12 Pro and 15 Pro for their cameras. For the regular line, this would of course still leave a wide array of devices (18 in total), here it would make most sense to just split iPhone 1 through 8 and iPhone XR through the current iPhone 16). From there on out, it may make most sense to just split every 10th iPhone (iPhone 20, 30, etc.) for all lines.YannickFran (talk)16:19, 5 January 2025 (UTC)[reply]
I partially reorganized the article by making "Supported" and "Unsupported" subheadings with smaller subheadings for the other distinctions.
So far, I agree with you in some aspects.
The 64-bit CPU distinction should be dropped. An unsupported device is an unsupported device. Furthermore, the switch to 64-bit happened long ago with the iPhone 5S, which has been unsupported for a long time.
The distinction between regular and plus/max models is mostly superfluous and can be resolved with delineating the differences within the columns.Cnscrptr (talk)18:23, 7 February 2025 (UTC)[reply]
I also think we can move the "Apple intelligence" row to the top for relevance and compensation for the removal of the Apple intelligence distinction in subheaders.Cnscrptr (talk)18:28, 7 February 2025 (UTC)[reply]
Just to further illustrate this, the end result would be roughly this:
Entry-level: covering the iPhone 5C, SE, SE 2, SE 3, 16e and future models.
Main: split in 2 "decades"
iPhone, 3G, 3GS, 4, 4S, 5, 5S, 6, 6S, 7, and 8
X, XR, 11, 12, 13, 14, 15, 16, 17, and hypothetically the iPhone 18 and 19
Air: right now just Air
Pro: XS, 11 Pro, 12, Pro, 13 Pro, 14 Pro, 15 Pro, 16 Pro, 17 Pro, and hypothetically the iPhone 18 Pro and 19 Pro
With the cut-off point being every time we hit a multiple of the 10th generation (first iPhone, iPhone X, and the presumably iPhone 20 in a few years from now). To not end up having awkward single device tables (which in this scenario would be unavoidable for new lines like the iPhone Air), as an example we could take the iPhone 20 and keep it in the table for the iPhone X up to iPhone 19 and split it off once the iPhone 21 comes out. This does assume that models that are simply size differences are just put in the same column.YannickFran (talk)13:51, 17 September 2025 (UTC)[reply]
I just fixed the contradictory definition of support in the article and classified any discontinued devices still receiving any form of software updates as "Discontinued but Supported". The Supported/Not Supported headers were changed as a temporary measure. (We can't have the legend define support one way and the table in a different way)
I think we can maintain the supported/unsupported distinction based on this fixed definition (we will determine if a device is supported based on when Apple stops maintaining the latest version it supports either silently (for a period of 1-2 years) or officially).
My proposal is to have a single table for supported devices and another for unsupported devices, no matter how long the tables get. However, your proposal is also interesting.Cnscrptr (talk)22:40, 20 September 2025 (UTC)[reply]
I don't think anyone wants a table that will keep growing endlessly. The idea here also is to not have to move devices around from one table to the next whenever an undetermined threshold is crossed. It's unnecessary maintenance and, in my opinion, can discourage new editors from contributing.YannickFran (talk)09:29, 21 September 2025 (UTC)[reply]
For ease of visibility for all groups in Wikipedia, particularly those affected by colorblindness, we should develop a colorblind-friendly palette that takes into account all types (red-green colorblindness in particular, the most common one).My recommendations:
Differences in brightness to adjust for achromatopsia
A color scheme that is palatable to at least the majority of colorblind people by making colors as distinguishable as possible for all groups.
Wikipedia has been dedicated to colorblind-friendliness, encouraging red-blue over red-green schemes. This dedication to accessibility makes articles easier to read for all readers.
- So far, I've implemented a red-green colorblind-friendly palette (green to blue) and have modified the "Upcoming" category (blue to purple to red) for tritanopes.Cnscrptr (talk)18:12, 7 February 2025 (UTC)[reply]
P.S. I haven't yet implemented the color scheme in other articles amid the discussion of a potentially better colorblind-friendly palette.Cnscrptr (talk)18:29, 7 February 2025 (UTC)[reply]
When has Wikipedia encouraged red-blue over red-green schemes? Even the accessibility guidelines don't talk about this at all, but rather discourage the use of colors as the only way information is conveyed and to assure high contrast (MOS:COLORS). And this is exactly what the table does; for those with color blindness, the table still conveys that information. But colors themselves have meaning (both in general, and in this case specifically), and in this specific instance that meaning is wide-spread across Wikipedia in various articles and various templates. Changing the colors around just moves the problem from one type of color blindness to the next. Red-green color blindness is the most common color blindness, but if the goal is to target the largest audience (which frankly; we should) then targeting no color blindness is the way to go. The table is fully accessible without the colors, they are just an aid. Making the coloring system confusing (contradictory to how they are used elsewhere and just the general meaning of colors (e.g. red means stop)) for 90% of the population isn't the solution here. Ideally Wikipedia has options to deal with this itself, but furthermore, accessibility tools outside Wikipedia can already help out with color blindness. We should absolutely accommodate color blindness and other accessibility issues, but that should not impede on the usability of Wikipedia for other users.YannickFran (talk)20:05, 7 February 2025 (UTC)[reply]
When has Wikipedia encouraged red-blue over red-green schemes? Even the accessibility guidelines don't talk about this at all, but rather discourage the use of colors as the only way information is conveyed and to assure high contrast (MOS:COLORS).
This is a precedent rather than a guideline, although it is one that we should follow.
Changing the colors around just moves the problem from one type of color blindness to the next.
This is exactly why this discussion was opened; to develop a color scheme that is usable by most colorblind and non-colorblind readers, if not all readers. For now, targeting red-green colorblindness is a step forward (although the change from purple to red should be reviewed).
then targeting no color blindness is the way to go
At the expense of other readers when the color system can be improved.
Making the coloring system confusing
I admit the color red for upcoming wasn't a good choice, but what color should we use for it? (For now, I'll revert to purple since it still helps red-green colorblindness)
You pointed out purple was problematic (which it was for tritanopes) when it can also symbolize something new for non-colorblind users.
Likewise, blue has often substituted green in various cases and can likewise mean good/positive/recent.
Perhaps the problem you find is how links are also blue and purple.
For now, we should keep these colors (blue and purple) since they are in no way problematic.
----
The goal of this discussion is to find a colorblind-friendly palate for the legend to make it accessible to the most users possible. I recommend keeping the "neutral, yellow, blue, purple" scheme for now, although reverting to the previous scheme is fine by discretion while this discussion takes place.Cnscrptr (talk)22:10, 7 February 2025 (UTC)[reply]
The situation for the colors in the Weather project, where the color was the only way a data point was distinguished on a map, is different from a situation where the color is substituted by the data in a table. I absolutely agree with the discussion held there however, that situation and the reasons for it simply don't apply here. The accessibility of the table is already handled by its contents, the colors are just to help visualize it, they aren't the primary way the information they hold is conveyed to the reader. And again; these colors are widely used across Wikipedia, and people will rightfully expect their meaning to be (at least roughly) the same across articles and for that meaning to be logical and consistent.
This is in my opinion a discussion that should be held higher up so it can be discussed with more people and impact all relevant pages if/when a consensus is reached rather than on a talk page of a comparison article.YannickFran (talk)23:31, 7 February 2025 (UTC)[reply]
The table/legend's end of support contradicts that of the support ended column. The end of support column lists the datea device stopped obtaining bug fixes or any type of software support (as agreed upon during the debate before table standardization across English Wikipedia), but the table and legend define end of support based onwhen devices stop receiving major updates.
Done. I reclassified all discontinued devices still receiving software updates as "Discontinued but Supported", rewrote the legend's definition of support, and added the "Security updates only" distinction in the summary table support column. Thus, the contradiction has been cleared.
The Supported/Not Supported headers were changed to Supporting/Not Supporting latest iOS version until the Reorganize article discussion concludes.Cnscrptr (talk)22:27, 20 September 2025 (UTC)[reply]
Split 64-bit unsupported into with neural engine/without neural engine
As "Not supported - 64 bit CPU" section is becoming longer and longer. If we keep adding devices into that list, we will get up to 33 devices in the list in the future, this will be too long.
I would like to propose to split into two sections:
Not supported - 64-bit CPU - without Neural Engine: From iPhone 5S to iPhone 7 Plus, total of 8 models
Not supported - 64-bit CPU - with Neural Engine, without Apple Intelligence: From iPhone 8 to iPhone 15 Plus, total of 25 models
Not supported - 64-bit CPU - with Apple Intelligence: From iPhone 15 Pro to iPhone 17 Pro Max, total of 11 models. Ignore this, as this will only happen after 5 years
Much like the split between 32 and 64 bit, splitting between Neural Engine and no Neural Engine is just pushing the problem down the road and we'll be hunting for yet another arbitrary split point. I still think my proposed solution to split up between lines (SE/e, Main, Air and Pro) makes more sense and to split there between decades (1st iPhone to 8, and X to current, etc). One day I may spend time implementing it if nobody solves it before me. :)YannickFran (talk)13:41, 17 September 2025 (UTC)[reply]
Instead of splitting into different product lines, what if we change to split by device generations (2 to 3 generations in a table, each table shall not exceed 9 devices). Assume that we ignore 32-bit devices as it won't be added into the table anymore.
In my opinion that's still rather arbitrary. Why would we want to compare the 11 vs the SE 2 vs the 12 (or base 11 and 12 vs their Pro counterparts)? I can see the appeal for it for during the time a phone is the latest devices in its bracket, but that feels more like we're doing Apple's marketing for them rather than write an encyclopedia, there are plenty of tools out there that will do a better job at that anyways. It makes more sense to me to compare phones with their actual predecessors and successors to give readers a sense of progression (or regression) rather than devices that aren't really in the same bracket and having to constantly jump back and forth between yes or no (or whatever spec any row may discuss).YannickFran (talk)15:44, 17 September 2025 (UTC)[reply]
or what if, we just split one generation one table (from sept to next year august as a cycle)
That makes more sense to me than combining a varying number of generations (although for pre-iPhone X this makes less sense). Still, I don't see much value in comparing SE vs Base vs Air vs Pro. A comparison across generations makes more sense to me. Just to reiterate too; I think different sizes should also just be in a single column rather than treating them as distinct devices.YannickFran (talk)14:39, 18 September 2025 (UTC)[reply]
Different size should be in separate column. Why? Because there are some different technical specifications for some models with different size. For example, camera in iPhone 7, iPhone 8, iPhone 12 Pro and iPhone 15 Pro, with their larger size modelKLPeople (talk)12:57, 19 September 2025 (UTC)[reply]
1 aspect in such a long list of specifications of 4 models in a list of 34 models being different does in my opinion not really warrant the amount of space wasted by listing them separately. E.g. for the iPhone 7 and 8: both generations use the same camera for their base and Plus variants. If they'd remain split up, one table would have to show - as it does now - data in a A-B-A-B pattern, where if both sizes are simply treated as being a size difference these cells could be merged and make the comparison simpler in the process. They're more the exception than they are the rule. If I'm not mistaken that's also the only significant spec where this does happen (aside from the physical size, of course). Imo this is excessive for just 12 rows in tables with 193 rows. In total, in the worst case scenario, these devices differ in specs only 21 times of these 193 rows (2 of which are basic info, 7 are directly related to the size, 1 is an extra storage option that could easily be noted with "(Pro Max)", the rest is just the main camera). And in that case, for the 15 Pro, for the camera specs it's only the telephoto lens that is different. I think the compromise to have slightly taller cells is of higher quality in the end than keeping every model split, it would - in the case of the 15 Pro - also make it much clearer what the difference is between the Pro and the Pro Max because you'd now have a cell that specifically calls out the one difference instead of having to notice in (for example) the resolution spec that the telephoto has an optical zoom of 5x for one and 3x for the other.YannickFran (talk)22:37, 19 September 2025 (UTC)[reply]
No, I'd expect something more like what I've already suggested above instead of just recreating Apple's comparison page for singular generations. The iPhone 7 table in this shows how nonsensical it is to not combine the base and plus models into a single column and to not combine multiple generations to create an actual comparison. More then half of tbat table is just the row headings.YannickFran (talk)19:16, 30 September 2025 (UTC)[reply]
.jpg)