uikit-app-modernization

Name: uikit-app-modernization
Author: superagents-lab

234stars15forks

How to install uikit-app-modernization?

superagents-lab/xcode27-skills/uikit-app-modernization

$npx -y skills add superagents-lab/xcode27-skills --skill uikit-app-modernization

Installs into the current project.

Summary

Modernizes UIKit apps for multi-window environments by replacing legacy shared-state APIs with context-appropriate modern alternatives. This includes references to mainScreen, interfaceOrientation, application and scene lifecycle, as well as safe area inset updates.

Files · 1

View on GitHub

SKILL.md

1	# UIKit App Modernization Skill
2
3	## Purpose
4
5	Modernize UIKit apps to behave correctly on modern iOS by:
6	- Eliminating references to legacy shared-state APIs
7	- Migrating from application lifecycle to scene lifecycle
8	- Supporting dynamic scene sizing and multi-window environments
9
10	## Scope
11
12	This skill performs specific, targeted modernizations in both Swift and Objective-C codebases:
13	- Replace legacy shared-state APIs with context-appropriate modern APIs
14	- Migrate to scene-based lifecycle
15	- Update apps to support a resizable user interface by removing usage of:
16	- main screen (`UIScreen.mainScreen`, `UIScreen.main`)
17	- interface orientation (`interfaceOrientation`)
18	- assumptions of symmetric safe areas (`safeAreaLayoutGuide`, `safeAreaInsets`)
19
20	## Core Principles
21
22	1. Closest to consumer — Prefer information nearest the point of use (e.g., view's trait collection over window's).
23	2. Always apply a replacement when the target API is present. A TODO alone is a failure. An empty diff for a file containing the target API is also a failure. If the file contains the target deprecated API and a concrete replacement is feasible under any pattern in the active task's reference file, apply it. Only skip when the target API appears exclusively inside dead code (`#if 0`/`#endif`). When uncertain between two valid replacements, pick the one that best fits the user's request rather than producing an empty diff. Never silently skip a file: if you are unwilling to apply a change, talk to the user about possible options — never produce no output for it. Do not get stuck weighing edge cases on simple files; when the substitution is obvious, apply it and move on.
24	3. TODOs must be actionable. Every TODO you do leave must state (a) why the change is needed, (b) what the correct replacement would look like, and (c) any lifecycle or threading concerns. Place the TODO on its own line above the unchanged code — never inline. A vague TODO ("fix this later") is worse than no TODO; it consumes review attention without telling the next reader anything they couldn't infer.
25	4. Don't add a redundant TODO when an existing annotation already covers the migration. If the call site already has a `#pragma clang diagnostic ignored` paired with a bug-report reference, an existing `// TODO`, or a deprecation comment that points at the migration, do not add another one. Only add a new TODO when it provides additional migration guidance not present in the existing annotation.
26	5. Ask the user before making a risky code change; fall back to a TODO only when interactive guidance is unavailable. When a replacement risks breaking callers or changing observable behavior (e.g., changing a method signature in a header that other modules import; substituting `width > height` for orientation when left-vs-right matters), the first move is to ask the user how to proceed. Only when the skill is running non-interactively, or when the user explicitly declines to provide guidance, drop a TODO and move on. This does not apply to standard, drop-in safe replacements specified by the active task's reference file — those must be applied per Core Principle 2.
27	6. Honor explicit user instructions; otherwise apply the defaults from the task reference file. When the user asks for a specific approach — a particular attribute, parameter name, parameter position, trait source, or fallback behavior — use that exactly. Don't silently substitute what you consider the modern equivalent. When the user is general ("modernize this app", "fix `UIScreen.main` usages"), apply the defaults from the active task's reference file.
28	7. Never replace dynamic values with literals — Always keep replacements dynamic.
29	8. Preserve control flow — Prefer drop-in replacements that maintain the original code structure. Only add guard/early-return patterns when a direct substitution does not work. When editing code around control flow (`if`/`else`, `switch`/`case`/`default`, `do`/`catch`), verify that the branching structure is preserved after your edit. Never remove a branch (`} else {`, `default:`, `catch`) unless the user explicitly asks for it. A diff that collapses an `if`/`else` into sequential execution is a critical bug — both branches will execute unconditionally.
30	9. Stay in scope — no opportunistic cleanup. Only modify lines containing the target deprecated API for the active task. Do NOT also fix other deprecation that happens to live nearby. Do NOT trim trailing whitespace, reformat blank lines, or "clean up" surrounding formatting. Even if you see an obvious modernization opportunity on an adjacent lin

People who liked this also viewed

6 picks

Type

uikit-app-modernization

234stars15forks

View on GitHub

How to install uikit-app-modernization?

superagents-lab/xcode27-skills/uikit-app-modernization

$npx -y skills add superagents-lab/xcode27-skills --skill uikit-app-modernization

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# UIKit App Modernization Skill
2
3	## Purpose
4
5	Modernize UIKit apps to behave correctly on modern iOS by:
6	- Eliminating references to legacy shared-state APIs
7	- Migrating from application lifecycle to scene lifecycle
8	- Supporting dynamic scene sizing and multi-window environments
9
10	## Scope
11
12	This skill performs specific, targeted modernizations in both Swift and Objective-C codebases:
13	- Replace legacy shared-state APIs with context-appropriate modern APIs
14	- Migrate to scene-based lifecycle
15	- Update apps to support a resizable user interface by removing usage of:
16	- main screen (`UIScreen.mainScreen`, `UIScreen.main`)
17	- interface orientation (`interfaceOrientation`)
18	- assumptions of symmetric safe areas (`safeAreaLayoutGuide`, `safeAreaInsets`)
19
20	## Core Principles
21
22	1. Closest to consumer — Prefer information nearest the point of use (e.g., view's trait collection over window's).
23	2. Always apply a replacement when the target API is present. A TODO alone is a failure. An empty diff for a file containing the target API is also a failure. If the file contains the target deprecated API and a concrete replacement is feasible under any pattern in the active task's reference file, apply it. Only skip when the target API appears exclusively inside dead code (`#if 0`/`#endif`). When uncertain between two valid replacements, pick the one that best fits the user's request rather than producing an empty diff. Never silently skip a file: if you are unwilling to apply a change, talk to the user about possible options — never produce no output for it. Do not get stuck weighing edge cases on simple files; when the substitution is obvious, apply it and move on.
24	3. TODOs must be actionable. Every TODO you do leave must state (a) why the change is needed, (b) what the correct replacement would look like, and (c) any lifecycle or threading concerns. Place the TODO on its own line above the unchanged code — never inline. A vague TODO ("fix this later") is worse than no TODO; it consumes review attention without telling the next reader anything they couldn't infer.
25	4. Don't add a redundant TODO when an existing annotation already covers the migration. If the call site already has a `#pragma clang diagnostic ignored` paired with a bug-report reference, an existing `// TODO`, or a deprecation comment that points at the migration, do not add another one. Only add a new TODO when it provides additional migration guidance not present in the existing annotation.
26	5. Ask the user before making a risky code change; fall back to a TODO only when interactive guidance is unavailable. When a replacement risks breaking callers or changing observable behavior (e.g., changing a method signature in a header that other modules import; substituting `width > height` for orientation when left-vs-right matters), the first move is to ask the user how to proceed. Only when the skill is running non-interactively, or when the user explicitly declines to provide guidance, drop a TODO and move on. This does not apply to standard, drop-in safe replacements specified by the active task's reference file — those must be applied per Core Principle 2.
27	6. Honor explicit user instructions; otherwise apply the defaults from the task reference file. When the user asks for a specific approach — a particular attribute, parameter name, parameter position, trait source, or fallback behavior — use that exactly. Don't silently substitute what you consider the modern equivalent. When the user is general ("modernize this app", "fix `UIScreen.main` usages"), apply the defaults from the active task's reference file.
28	7. Never replace dynamic values with literals — Always keep replacements dynamic.
29	8. Preserve control flow — Prefer drop-in replacements that maintain the original code structure. Only add guard/early-return patterns when a direct substitution does not work. When editing code around control flow (`if`/`else`, `switch`/`case`/`default`, `do`/`catch`), verify that the branching structure is preserved after your edit. Never remove a branch (`} else {`, `default:`, `catch`) unless the user explicitly asks for it. A diff that collapses an `if`/`else` into sequential execution is a critical bug — both branches will execute unconditionally.
30	9. Stay in scope — no opportunistic cleanup. Only modify lines containing the target deprecated API for the active task. Do NOT also fix other deprecation that happens to live nearby. Do NOT trim trailing whitespace, reformat blank lines, or "clean up" surrounding formatting. Even if you see an obvious modernization opportunity on an adjacent lin

People who liked this also viewed

6 picks

Type