Remove unnecessary UIKit imports - #25812
Open
jkmassel wants to merge 1 commit into
Open
Conversation
Collaborator
Generated by 🚫 Danger |
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 34144 | |
| Version | PR #25812 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | e89ab07 | |
| Installation URL | 6ng39u4iggrh8 |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 34144 | |
| Version | PR #25812 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | e89ab07 | |
| Installation URL | 7ns49jk18aro0 |
jkmassel
force-pushed
the
jkmassel/remove-unused-uikit-imports
branch
from
September 1, 2026 23:25
df2edc9 to
8894295
Compare
Sweep files that import UIKit but reference no UIKit symbol. Where the import only provided Foundation via re-export, switch to `import Foundation`; CATransaction+Extension moves to `import QuartzCore` since CATransaction is Core Animation. Imports only, no behavior change. Files that declare or extend a UIKit-rooted type keep their import even though nothing in them names a UI* symbol — the dependency is real, it is just inherited rather than spelled. Follow-up to #25344.
jkmassel
force-pushed
the
jkmassel/remove-unused-uikit-imports
branch
from
September 1, 2026 23:43
8894295 to
e89ab07
Compare
jkmassel
marked this pull request as ready for review
September 1, 2026 23:58
crazytonyli
approved these changes
Sep 2, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Removes
import UIKitfrom files that reference no UIKit symbol — a follow-up to the cross-platform module split in #25344, where a stray UIKit import is what keeps a file (or an entire module) from compiling on platforms without UIKit.Summary
import UIKitcount drops from 946 → 907.WordPress/,Modules/,Sources/, andTests/. Every candidate was found by a heuristic pass (noUI*identifier, no UIKit-onlyNS*type, no UIKit extension-on-Foundation call) and then read individually to confirm.Changes
import UIKit→import FoundationURL,NSCoder,NSLocalizedString,SortDescriptor,HTTPCookieStorage, …) that UIKit was only re-exportingimport UIKitremovedimport UIKit→import QuartzCoreCATransaction+Extension.swift—CATransactionis Core Animation, not UIKit; a plain Foundation swap would not compileUIKit re-exports Foundation, so the Foundation swaps are load-bearing — deleting the import outright would break any file leaning on it for
URL/NSCoder/etc.SwiftUI,XCTest,CoreLocation, andWordPressDatado not reliably re-export Foundation.What we deliberately left alone
A first pass caught 17 more files that compile fine without
import UIKitbut were left untouched on purpose: each one declares or extends a type whose superclass chain roots in UIKit, so the dependency is real — it is inherited rather than spelled.PeopleRoleBadgeLabelis the clearest example:Nothing in that file names a
UI*symbol, so the compiler does not need the import — Swift only requires a module import to name its types, and inherited member lookup walks the superclass chain regardless. But dropping it would buy nothing: the file can never compile without UIKit, because its superclass is aUILabel. It would only hide a real dependency and break the next edit that names a UIKit type.Same reasoning for the other 16 —
WebKitViewController/TemplatePreviewViewController/BaseRestoreStatusViewControllersubclasses (all →UIViewController),ReaderBaseHeaderViewsubclasses (→UIView), and extensions onWebKitViewController,ListTableViewCell, andStatsViewController.So the rule this PR applies is "the file has no UIKit dependency," not "the file names no UIKit symbol." Every one of the 39 files here is genuinely UIKit-free.
Test plan
xcodebuild build—WordPressscheme, iOS Simulator → BUILD SUCCEEDED, 0 errors (all 33 app/module source files)xcodebuild build-for-testing—WordPressUnitTestsplan → TEST BUILD SUCCEEDED, 0 errors (the 6 test files, across theWordPressTest,WordPressKitTests, andAsyncImageKitTeststargets)Related