# Port a mobile game that the app stores stopped accepting > Porting a mobile game means rebuilding a title you own. Store requirements, dead SDKs, and 64-bit rules break old builds long before the game stops being fun. - URL: https://www.summerengine.com/port-a-mobile-game - Keyword: port a mobile game - Related: https://www.summerengine.com/porting Porting a mobile game means rebuilding a game you own so it meets current store requirements and runs on new platforms. Mobile games do not usually break because the design aged. They break because platform rules moved: Apple dropped 32-bit app support with iOS 11, Google Play raises its target API level requirement every year, and privacy and permission rules keep changing. An app that is not updated gets delisted. You need the rights to the game. That is usually simple for your own app, but check contracts if a publisher, a work for hire studio, or a licensed brand was involved. Summer Engine rebuilds the game as one project with desktop builds for Steam and itch.io. iOS and Android builds need that platform's toolchain and signing (the Android SDK and a keystore, or a Mac with Xcode for iOS) and a pass on touch input. You own the project and pay no royalties. ## Why the old build stopped working The usual causes are mechanical. 32-bit binaries stopped being accepted on iOS. Google Play requires apps to target a recent API level to stay listed and updatable. Old ad, analytics, and social SDKs stopped being maintained, and some now break at runtime. Deprecated permission models cause rejections. None of that is a gameplay problem, which is why a rebuild can produce a shippable game quickly once the platform layer is modern. ## What to strip before rebuilding Make an inventory of every third party SDK in the old project: advertising, analytics, attribution, crash reporting, social login, push notifications, and in-app purchase wrappers. Most of them are dead or replaced. Rebuild with only what you actually need, because each SDK adds store compliance work, privacy disclosures, and a dependency that can break the build later. Games that shipped in the ad heavy era frequently sell better now as a paid version with no SDKs at all. ## Screens changed shape since your game shipped A game built for a 4:3 or 16:9 phone now runs on 19.5:9 and 20:9 displays with notches, camera cutouts, gesture bars, and rounded corners. Fixed pixel UI layouts break on all of them. Rebuild the UI with anchors and safe area insets so controls stay reachable and nothing important sits under a cutout. Also recheck touch target sizes, since screens are physically larger but thumbs are not. ## Taking a touch game to desktop Desktop is the most common second target and it needs more than a mouse binding. Touch drags become click drags, pinch zoom becomes a scroll wheel, and multitouch gestures need an explicit alternative. Add keyboard controls, window handling, and larger fonts for a monitor viewing distance. A free desktop demo on itch.io is a good way to test the controls before a Steam launch. A GDScript project also exports a web build that you publish on Summer Games. ## Rebuilding purchases and progression In-app purchase implementations age badly, and receipt validation rules have changed on both stores. Rebuild purchases against current store APIs rather than porting the old code. If the game had server backed progression, decide whether to keep a backend or move to local saves with cloud sync, which is simpler and cheaper for most single player games. Preserving old player save data is possible if you document the format, and it is worth doing for a returning audience. ## FAQ ### Why was my old mobile game removed from the app store? Almost always platform rules rather than content. Apple stopped supporting 32-bit apps with iOS 11, and Google Play requires apps to target a recent API level to remain listed and updatable. Unmaintained apps also fail current privacy and permission requirements. ### Can I reuse my old mobile game code? Use it as a specification. Gameplay logic, balance values, and level data all transfer. The platform layer does not: old SDKs, purchase code, permission handling, and rendering paths are rebuilt against current requirements. ### Can a mobile game be ported to Steam? Yes, and it is a common move. From one Summer Engine project you export desktop builds for Steam. Desktop needs real work beyond a mouse binding, including keyboard controls, window handling, larger fonts, and alternatives for multitouch gestures. ### How do I handle notches and tall phone screens? Rebuild the UI with anchors and safe area insets instead of fixed pixel positions. Modern phones use 19.5:9 or 20:9 displays with camera cutouts, gesture bars, and rounded corners, so anything positioned absolutely will overlap something on some device. ### Should I keep the old ad and analytics SDKs? Usually not. Most are unmaintained or replaced, and every SDK adds compliance work, privacy disclosures, and a dependency that can break your build. Many games from the ad heavy era perform better rebuilt as a paid version with no third party SDKs. [Rebuild your mobile game](https://www.summerengine.com/download) --- ## Machine-readable resources - Site index for agents: https://www.summerengine.com/llms.txt - Full inlined content: https://www.summerengine.com/llms-full.txt - Porting catalog: https://www.summerengine.com/llms-porting.txt - Structured catalog: https://www.summerengine.com/agent-catalog.json - Sitemap: https://www.summerengine.com/sitemap.xml - Developer resources: https://www.summerengine.com/docs