Porting a PC or console game to mobile is one of the most technically demanding challenges in game development. It is not a simple rebuild. Every assumption your game makes about input, screen size, processing power, memory, and player session length needs to be reconsidered. Teams that treat a mobile port as a "downscale and ship" exercise end up with a product that feels awkward, runs poorly, and haemorrhages players within the first week.
I led the mobile porting effort for RuneScape Mobile at Jagex between 2017 and 2019, adapting a 20-year-old Java-based MMO with a complex UI and deep systems to run on phones and tablets. Since founding Ocean View Games, our team has continued porting Unity titles across genres and complexity levels. The lessons from those projects inform everything in this guide.
Before starting a port, assess whether your game is ready. Our porting feasibility guide covers that assessment in detail. This post picks up where that guide leaves off, walking through the practical work of actually executing a mobile port in Unity.
Input Remapping and UI Adaptation
Input is where most ports succeed or fail. A PC game designed around mouse precision and keyboard shortcuts cannot simply have virtual buttons overlaid on the screen. The entire interaction model needs rethinking.
Touch Controls vs Traditional Input
A mouse cursor provides hover states, right-click context menus, and pixel-level precision. A finger on a touchscreen provides none of these. The gap between these input paradigms is larger than most teams expect, and closing it requires genuine design work rather than surface-level adaptation.
RuneScape Mobile is a good example of the scale of this challenge. The desktop game had evolved over 20 years with an interface built around right-click context menus, small inventory icons, a minimap, and dozens of on-screen buttons. None of that translated to touch. The mobile team had to rebuild the entire interaction model: replacing right-click menus with long-press radial menus, enlarging interactive elements, collapsing multiple toolbars into tabbed panels, and rethinking how players navigate a vast 3D world with two thumbs instead of a keyboard and mouse. It was not a reskin. It was a fundamental redesign of how players interact with the game.
XCOM 2 Collection on iPad faced a different but equally instructive challenge. The desktop game relies on precise cursor placement for unit selection, targeting, and camera control. The iPad port replaced mouse hover with tap-to-select, added a dedicated camera rotation gesture, and enlarged the targeting reticle so that finger-based aiming felt deliberate rather than clumsy. The result worked because the team treated touch as a first-class input method rather than a fallback.
Haptic feedback is an often overlooked tool for improving touch controls. Modern iOS devices support the Core Haptics API, and Android provides the VibrationEffect system for fine-grained vibration patterns. Short, crisp haptic pulses on button presses, successful attacks, or UI confirmations give players tactile feedback that compensates for the lack of physical buttons. Used well, haptics make touch controls feel more responsive and satisfying. Used poorly (constant vibration, heavy rumbles), they drain battery and annoy players.
Screen real estate is the biggest constraint. A 6-inch phone display has roughly 15% of the usable area of a 24-inch monitor. UI elements that worked at desktop scale become illegible or untappable at mobile scale. The general rule is that any interactive element needs a minimum touch target of 44x44 points (Apple's Human Interface Guidelines) or 48x48 dp (Material Design). That eliminates most desktop-style toolbars and nested menus.
Practical Approaches
Contextual controls work best for complex games. Rather than showing every action at once, surface controls based on what the player is doing. RuneScape Mobile used this approach extensively, showing combat abilities only during combat and skilling interfaces only when interacting with relevant objects.
Virtual joysticks are appropriate for action games with direct character movement. They work poorly for strategy, simulation, or menu-heavy games. Gesture recognition (pinch-to-zoom, swipe-to-rotate) supplements touch controls well but should never be the only input method for critical actions. Players need visual affordances showing them what gestures are available.
Sometimes the right answer is to simplify mechanics. Albion Online removed some mouse-driven inventory management when porting to mobile, replacing drag-and-drop with tap-based interactions. Dead Cells adapted its fast-paced combat with customisable virtual button layouts, giving players control over where buttons sit on screen. These are design decisions, not just technical ones, and they need to happen early in the porting process.
Performance and Thermal Management
Mobile hardware is powerful but thermally constrained. A modern flagship phone has a GPU comparable to a mid-range laptop, but it sits inside a thin metal or glass shell with no active cooling. After 10 to 15 minutes of sustained load, the device's thermal management system kicks in and throttles the CPU and GPU, sometimes by 40% to 60%. A game that runs at 60fps in the first five minutes and drops to 25fps after fifteen minutes has a thermal problem, not a performance problem.
Profiling Workflow
Effective profiling requires testing on real devices in realistic conditions. The Unity Profiler provides frame timing, memory allocation, and rendering statistics. For iOS, Xcode Instruments offers Metal System Trace for GPU profiling and the Allocations instrument for memory tracking. On Android, the Android GPU Inspector gives detailed render stage breakdowns and counter data.
Profile on mid-range devices, not flagships. A Samsung Galaxy A54 or Pixel 7a represents what most of your players will actually use. Profile in a warm environment. A device sitting on a desk in an air-conditioned office will throttle later than one in a player's hands on a summer commute. Run profiling sessions for at least 20 minutes to capture thermal throttle behaviour.
Common Optimisations
Draw call batching is often the single biggest performance win. Mobile GPUs handle fewer draw calls efficiently than desktop GPUs. Use Unity's SRP Batcher with URP, enable GPU instancing for repeated objects, and merge static geometry where possible. Aim for under 200 draw calls on low-tier devices.
Texture compression with ASTC (Adaptive Scalable Texture Compression) gives the best quality-to-size ratio on modern mobile hardware. ASTC is supported on all iOS devices from the A8 chip onward and on most Android devices shipping since 2015. The block size you choose determines the trade-off between visual quality and memory usage. ASTC 4x4 delivers the highest quality at roughly 8 bits per pixel, making it the right choice for UI elements, normal maps, and any texture where compression artefacts would be noticeable. ASTC 6x6 at approximately 3.6 bits per pixel is the sensible default for most game textures, offering a good balance of quality and size. ASTC 8x8 at around 2 bits per pixel is aggressive compression best suited to large background textures, skyboxes, and terrain where fine detail is less critical. Getting the block size right across your asset library can reduce total texture memory by 40% to 60% compared to uncompressed or poorly configured formats.
LOD management (Level of Detail) is essential. Desktop games often render high-poly models at distances where mobile screens cannot display the detail anyway. Aggressive LOD switching, dropping to 25% triangle count at medium distance, saves substantial GPU time without visible quality loss on a small screen.
Shader simplification often means replacing desktop shaders with mobile-specific variants. Standard PBR with multiple texture maps can be replaced with simplified lit shaders using fewer samplers. Baked lighting reduces runtime cost significantly for static environments. Shader variant stripping is another important step that teams frequently overlook. Unity compiles shader variants for every possible keyword combination, and a complex shader can generate thousands of variants, most of which your project will never use. Use Unity's shader variant stripping callbacks or the Shader Variant Collection tool to identify and exclude unused variants. This reduces build size, speeds up load times, and lowers runtime memory consumption.
Memory Budgets by Device Tier
Realistic memory budgets vary significantly across the device spectrum, and the numbers are tighter than many PC developers expect. The operating system, background services, and system processes all consume RAM before your game gets any of it.
| Device tier | Memory budget |
|---|---|
| Low tier Android (2GB RAM total) | The OS and background services consume roughly 1.2GB, leaving approximately 800MB for your application. In practice, staying under 600MB to 700MB is safer to avoid low-memory kills. This tier requires aggressive asset streaming, lower-resolution textures, and careful management of loaded scenes. |
| Mid tier Android (4GB RAM total) | With the OS overhead, roughly 1.5GB is available for your application. Budget around 900MB to 1.2GB to leave headroom. This is where most of your Android players sit, and it should be your primary optimisation target. |
| High tier Android (8GB+ RAM) | 2GB or more is available, but do not design for this as your baseline. Use the extra headroom for higher-quality assets on capable devices rather than treating it as your minimum requirement. |
| iOS (3GB iPhone, typical of iPhone 13 and similar) | iOS manages background apps aggressively, freeing up more memory for the foreground application. Around 1.8GB is a safe working budget on a 3GB device. However, exceeding the Jetsam memory limit triggers an immediate, silent crash with no warning dialog and no chance to save state. Monitor memory pressure using os_proc_available_memory() and implement fallback asset loading before you approach the limit. |
For a deeper dive into sustained performance, read our post on managing thermal throttling in Unity mobile. If you need hands-on help, our performance optimisation services cover profiling, optimisation, and thermal management for mobile Unity projects.
Platform-Specific Considerations
iOS and Android have different rendering APIs, submission processes, and fragmentation profiles. A successful port accounts for both from the start.
iOS
Apple's Metal API is the only supported graphics API on iOS. Unity handles Metal rendering through URP or the built-in render pipeline, but certain shader features and compute operations behave differently under Metal than under DirectX or Vulkan. Test shader behaviour on actual iOS hardware early.
App Store review adds time and unpredictability to your release schedule. Apple's reviewers will reject builds for performance issues, crashes, and UI that does not conform to Human Interface Guidelines. Budget one to two weeks for the review cycle, and expect at least one rejection on your first submission. TestFlight is essential for beta distribution and supports up to 10,000 external testers, making it a powerful tool for gathering performance data across device models before launch.
Minimum OS targeting requires a careful balance. Supporting iOS 15 and above covers roughly 95% of active devices. Dropping to iOS 14 picks up a few percent more but introduces compatibility constraints with newer Metal features and Swift runtime requirements. Check Apple's published adoption statistics for current figures.
Android
Device fragmentation is the defining challenge of Android development. Over 4,000 active device models span a vast range of chipsets, screen sizes, and OS versions. Your game will encounter Qualcomm Adreno, ARM Mali, and Imagination PowerVR GPUs, each with different performance characteristics and driver quirks.
Vulkan is the preferred graphics API for modern Android devices, offering better CPU overhead characteristics than OpenGL ES 3.x. However, Vulkan driver quality varies significantly by manufacturer. Samsung and Google Pixel devices generally have solid Vulkan support. Some budget MediaTek and older Qualcomm chipsets have Vulkan implementations that are technically present but practically unreliable. A common strategy is to default to Vulkan on known-good devices and fall back to OpenGL ES 3.2 on others, using a device capability list.
Android App Bundles (AAB) are now required for Google Play submissions. AABs enable dynamic delivery, letting you ship device-appropriate assets (resolution, texture compression format) without bloating the initial download. The initial install limit is 200MB for the base APK, with additional content delivered via Play Asset Delivery.
Google Play policies around permissions, data safety declarations, and target API level requirements change frequently. As of 2026, new apps must target at least API level 35 (Android 15). Budget time for policy compliance alongside technical development.
Cross-Platform Considerations
For both platforms, link to our platform readiness guide for the full pre-submission checklist covering store metadata, rating questionnaires, privacy declarations, and compliance requirements.
Testing and Device Coverage
You cannot test on every device. The goal is to build a device matrix that covers the range of hardware your players will use, then supplement physical testing with cloud-based device farms.
Building a Device Matrix
Start with analytics data if your game has a PC or web presence. Your existing audience's mobile device distribution tells you what to prioritise. Without existing data, a reasonable matrix for a global audience includes 8 to 12 physical devices:
| Platform | Recommended devices |
|---|---|
| iOS (3 to 4 devices) | iPhone SE 3rd gen (baseline, smallest screen, A15 chip), iPhone 13 (mid tier, representative of the largest active iOS segment), iPhone 15 Pro (high tier, A17 Pro, ProMotion 120Hz), and an iPad Air for tablet layout testing |
| Android (5 to 8 devices) | Samsung Galaxy A14 (low tier, MediaTek Helio, Mali GPU, 2 to 4GB RAM), Pixel 7a (mid tier, Tensor G2, Adreno GPU), Samsung Galaxy S23 (high tier flagship), Xiaomi Redmi Note 13 (high volume emerging market device), and ideally an older flagship like the Samsung Galaxy S20 or Pixel 5 to test aging high-end hardware with degraded battery and thermal performance |
The most important principle in device matrix construction is to test on the worst device you intend to support, not the best. If your minimum spec is a Samsung Galaxy A14, that device should be the one sitting on your desk every day during development. It is tempting to develop on a flagship and optimise for lower devices later, but that approach leads to architectural decisions that are expensive to reverse. Performance problems discovered late on low-end hardware often require fundamental changes to rendering, asset loading, or scene complexity rather than simple parameter tweaks.
Prioritise variety across four dimensions: chipset manufacturer (Qualcomm, MediaTek, Samsung Exynos, Apple), GPU family (Adreno, Mali, PowerVR), RAM tier (2GB, 4GB, 6GB, 8GB+), and screen size (compact phones, standard phones, large phones, tablets). Each combination can reveal unique issues that other configurations would miss.
Automated and Cloud Testing
Firebase Test Lab and AWS Device Farm provide access to hundreds of device models for automated test runs. These are excellent for catching device-specific crashes, layout issues, and compatibility failures. They are less useful for performance profiling, as virtualised or remote device environments do not replicate real thermal behaviour.
Automated UI testing with Unity Test Framework or Appium catches regression issues across builds. Smoke test suites that launch the game, navigate menus, and play through a short session on a matrix of devices save significant manual QA time.
For teams without an in-house QA function, our QA testing services provide device coverage testing, performance profiling, and compatibility validation across iOS and Android.
Timeline and Cost Expectations
Porting timelines depend on the complexity of the source game, the state of its codebase, and the depth of adaptation required. Here are realistic ranges based on our experience.
By Project Complexity
Simple ports (2D games, minimal UI, straightforward controls): 2 to 4 months with a small team (2 to 3 developers). Examples include puzzle games, card games, and simple action titles with existing touch-friendly mechanics.
Medium complexity (3D games, moderate UI, some systems redesign): 4 to 8 months with 3 to 5 developers. This covers most indie and mid-tier titles that need input reworking, performance optimisation, and UI adaptation.
Complex ports (MMOs, deep strategy, extensive systems, large asset libraries): 8 to 18 months with a dedicated team of 5 or more. RuneScape Mobile took approximately two years with a large team. Games with complex networking, large persistent worlds, or heavy content pipelines sit at this end. Multiplayer and online games face additional complexity from network stack adaptation, server infrastructure for mobile session patterns, and reconnection handling for unstable mobile connections, which is why MMO or multiplayer ports typically fall in the 6 to 12 month range even when the core gameplay is relatively straightforward.
These timelines assume the source codebase is in reasonable condition. Legacy codebases with heavy technical debt, hardcoded resolution assumptions, or tightly coupled platform-specific code add 30% to 50% to these estimates. Factor in additional time for platform submission and review cycles, particularly if your team has not shipped on iOS or Android before.
Use our game development cost estimator to build a rough budget based on your project's scope, and our game development timeline estimator to model realistic schedules for different project sizes. For a conversation about your specific project, explore our mobile development services or get in touch directly.
Conclusion
A successful mobile port requires deliberate decisions about input, performance, platform compliance, and testing. None of these areas can be treated as an afterthought. The games that port well to mobile are the ones where the team committed to rethinking the experience for the platform rather than simply shrinking the desktop version.
Start with a feasibility assessment, invest in proper thermal profiling on real devices, build your device matrix early, and budget realistically for the timeline. If your team needs specialist support, whether for the full port or for specific challenges like performance optimisation or platform submission, Ocean View Games has the experience to help. We have been through this process on projects ranging from MMOs to educational titles, and we know where the pitfalls are.
David Edgecombe is the founder and technical lead at Ocean View Games, a London-based game development consultancy. A Unity Certified Expert with over 10 years of Unity experience, David previously served as Mobile Team Lead at Jagex, where he led the porting effort for RuneScape Mobile from 2017 to 2019.
Top comments (0)