Talk:List of iPhone models

Removing the obsolete/vintage/unsupported distinction

Decided to be BOLD. 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/overlookYannick Fran ([[User talk:|talk]]) 19:22, 3 January 2025 (UTC)

That's a good idea especially since I don't think we need to update it indefinitely. Stephen"Zap" (talk) 14:52, 4 January 2025 (UTC)

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)

My opinion is that the distinction was useful and should be brought back. --HenriHa (talk) 03:14, 4 March 2025 (UTC)

Contradictory definitions of Support

The table/legend's end of support contradicts that of the support ended column. The end of support column lists the date a 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 on when devices stop receiving major updates.

It is necessary to come to a single definition of support to prevent confusion and for consistency's sake. Cnscrptr (talk) 14:14, 20 August 2025 (UTC)

What if we split into two: major support ended and security support ended? I remember we used to do that.

Eg: iPhone 5S major support ended on September 19 2019 but security support ended on January 23, 2023 KLPeople (talk) 14:28, 17 September 2025 (UTC)

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)

Edit: I've done as KLPeople suggested and added security support only to the legend (with the old orange that was used for unsupported devices). This is a distinction that is heavily relevant for Apple users, but to be more accurate and follow YannickFran's assessment, I've split support into two types (regular updates and security updates). Cnscrptr (talk) 19:41, 19 December 2025 (UTC)

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

Or is anyone has better idea? KLPeople (talk) 11:45, 16 September 2025 (UTC)

Do you disagree with YannickFran’s suggestions above? Primarily: #Reorganize article. I agree with their rough consensus that the 64-bit distinction is arbitrary. — HTGS (talk) 08:47, 17 September 2025 (UTC)

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)

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.

Eg:

• 5S - 7 (A7 - A8 - A9 - A10) - 8 iPhones
• 8 - X - XS - XR (A11, A12) - 6 iPhones
• 11 - SE2 - 12 (A13, A14) - 8 iPhones
• 13 - SE3 - 14 (A15, A16) - 9 iPhones
• 15 - 16 (A16, A17, A18) - 9 iPhones
• 17 - 4 iPhones

KLPeople (talk) 14:25, 17 September 2025 (UTC)

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)

or what if, we just split one generation one table (from sept to next year august as a cycle)

eg 8/8P/X is same generation, XS/XSM/XR, 11/11P/11PM/SE, etc KLPeople (talk) 13:17, 18 September 2025 (UTC)

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)

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 model KLPeople (talk) 12:57, 19 September 2025 (UTC)

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)

https://en.wikipedia.org/wiki/User:KLPeople/sandbox/iphone_in_a_table

Are you expecting something like this? KLPeople (talk) 16:19, 27 September 2025 (UTC)

@YannickFran KLPeople (talk) 23:02, 29 September 2025 (UTC)

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)

Instead of putting 16e in SE lineup, we can put it in 16 lineup as Apple mentioned that it's under iPhone 16 family KLPeople (talk) 14:26, 17 September 2025 (UTC)

Standardizing the classification of support

There has been trouble and confusion with how us editors can classify devices as supported, given that Apple has an irregular support policy. Devices that aren't receiving the latest iOS version receive security and minor updates at an irregular schedule, resulting in them not getting bug fixes for years until one comes out years later (as happened with iPhone 4S in 2019 and 5S and 6). Furthermore, new editors follow Apple's definition of support, leading them to classify devices that are still supported for bug fixes/minor updates as unsupported, which has become a hassle to constantly revert.

Thus, I propose we choose one of two ways of going about standardizing our classification of support:

• Using regular support as a metric: Although Apple does not state when a device stops receiving regular security updates, they do state when a device stops receiving major ones. This metric would allow us to rely on an official classification of support.
• Classifying devices as unsupported after not receiving security updates for a long time: Although this would require us to rely on our own original classifications and reasoning rather than one used by a source such as Apple, it would more accurately measure support. Since we do not know when Apple stops supporting a device, we would have to rely on a long amount of time that a device hasn't received a security/minor update, which could be 1, 2, or 3 years. We could also choose certificate extensions.

Based on which approach we use, we would add an IMPORTANT NOTE for editors that states

Alternatively, we could do the following (across all Apple and possibly all device lists):

• Get rid of the legend colors and lifespan (or rename the lifespan), rename the "Support" column or replace it with its subcolumns (or keep its name), and rename "Ended" to "Released". This move would remove the need for the table being updated constantly for support or release distinctions and instead only update it when a new device is released.

Cnscrptr (talk) 20:13, 19 April 2026 (UTC)

@YannickFran Maybe this might be of interest to you. Cnscrptr (talk) 07:13, 22 April 2026 (UTC)

Gonna throw another alternative in the mix where we actually do rely on Apple's documentation but aren't in an indefinite limbo to determine when support ends: Apple does properly document security issues they fix and in what version they appear. Once an older OS version doesn't receive (all) security fixes that it is vulnerable for but that are fixed in later versions, we stop considering it "Supported" (and in extension than stop considering any devices stuck on that version as such). For all intents and purposes, any update that follows that point would be more of an emergency fix and not really qualify as the full support that "Supported" already implies. This is in general also the logic I've already been applying for iOS, iPadOS, macOS, etc. pages and also is the closest match to determined end-of-life policies.

As an aside; I'm not sure this article's talk page is the correct place to discuss this? This probably applies more to iOS/iPadOS/whatever first, since that's what we base support on here in the first place. Maybe worth notifying other talk pages about potentially relevant discussions? YannickFran (talk) 10:12, 22 April 2026 (UTC)

I agree with your idea. Cnscrptr (talk) 04:52, 27 April 2026 (UTC)

From what I've seen (after discussing with an AI although it may be heavily inaccurate), no version is fully supported or not supported; rather, support is tiered across versions, e.g., iOS 26 gets all fixes, iOS 18 gets some fixes, and iOS 15 gets few fixes. Also, my concern with this approach toward determining support is that it could be too convoluted, although that does not justify abandoning it. Cnscrptr (talk) 18:31, 9 June 2026 (UTC)

Incorrect Information

Hello. I dont know how giving feedback on wikis works, so forgive me if this does not fit here. In the third paragraph of this wiki, the article incorrectly lists the 17e as being released on September 11 2001. I believe this is an error. ~2026-30401-33 (talk) 11:40, 21 May 2026 (UTC)