How to Prepare iOS Graphic Assets for Retina Screens

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
How to Prepare iOS Graphic Assets for Retina Screens
Simple
from 4 hours to 2 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

You’ve seen it: an icon looks perfect in Figma but turns blurry on an iPhone 15 Pro. Usually the culprit is incorrect export without accounting for screen densities. Sometimes this leads to App Store rejection under Apple Review Guidelines (Section 4.2: Design Minimum) which demands pixel-perfect elements. We fix such bugs daily and know how to avoid them. Based on 5+ years of iOS development experience, here’s a battle-tested recipe. Subpixel rendering and interpolation artifacts are common when scaling raster assets; our method eliminates them completely.

How iOS Densities Work

iOS operates in logical points (pt), not pixels (px). The iPhone SE (3rd gen) uses @2x (1 pt = 2 px), modern Pro models use @3x (1 pt = 3 px). For a 24×24 pt icon you need three files: icon.png 24×24 px (@1x, for simulator), [email protected] 48×48 px, [email protected] 72×72 px. Always verify that the Asset Catalog slot is correct – otherwise Xcode picks the wrong scale.

Why Not Just @2x?

The system can scale, but quality suffers: artifacts appear, anti-aliasing breaks thin lines. This is especially critical for icons with sharp corners or gradients. The difference is obvious on Retina displays. Moreover, Apple Review Guidelines (Section 5.1.2) may reject the app due to pixelated graphics. Optimized PNGs are up to 50% smaller than unoptimized ones, and PDF icons render 3x sharper at large sizes.

How to Export Properly from Figma

In Figma, set up three Export presets: 1x (empty suffix), 2x (suffix @2x), 3x (suffix @3x). Export all at once – this eliminates human error. Then in Xcode Asset Catalog, drop the files into the 1x, 2x, 3x slots. Xcode picks the right one for the device automatically.

Size (pt) @1x (px) @2x (px) @3x (px)
16×16 16×16 32×32 48×48
24×24 24×24 48×48 72×72
48×48 48×48 96×96 144×144

Step-by-Step Asset Preparation

  1. Prepare sources in Figma: ensure each element is on its own frame and exported without fill.
  2. Create three export presets with suffixes: no suffix, @2x, @3x.
  3. Export all assets with one command – Figma generates PNGs for all densities.
  4. Open Assets.xcassets in Xcode, drag files into corresponding slots or use an automation script.
  5. Run pngcrush on all PNGs – this removes extra metadata and reduces weight by 30–50%.

Vector or Raster: What to Choose?

For simple icons, use PDF in Asset Catalog with Preserve Vector Data flag – Xcode renders them as vectors, no rasterization needed. But complex multi-color illustrations with gradients are better as PNG: PDF sometimes renders gradients with banding. SVG is not natively supported (only macOS 11+), convert to PDF via Sketch.

Format Sharpness Weight Use Case
PNG High High Photos, complex gradients
PDF (vector) Perfect Low Icons, logos, simple shapes
SVG Vector only Medium Not supported on iOS < 11, convert to PDF

PNG Optimization Without Quality Loss

After export, run all PNGs through pngcrush -reduce -m 0 or optipng -o7. These tools remove extra metadata (color profiles, gamma) and improve compression. Typical gain – 30–50% weight. For large projects, this saves tens of megabytes. Additionally, you can configure a build phase in Xcode to auto-compress PNGs during compilation. Lossless optimization ensures zero quality degradation.

Common Asset Prep Mistakes

  • Exported all three scales? @1x is often forgotten, yet needed for simulator.
  • File names follow the pattern? [email protected], [email protected] (case matters).
  • Asset Catalog slot correct? Don’t confuse 1x and @2x.
  • For PDF, is Preserve Vector Data enabled? Otherwise Xcode rasterizes at build time.
  • PNGs compressed? pngcrush is mandatory before submission.
  • Check all assets against Apple Human Interface Guidelines – reference sizes and margins.
Detailed checklist for asset preparation - Verify all three density variants exist for each asset. - Confirm naming convention matches expected suffixes. - Test build on simulator and real device to catch missing assets. - Use Asset Catalog compiler to validate no duplicate entries. - Audit image compression ratio – aim for < 50% of original size.

What’s Included in Our Service

  • Export and resampling of all assets to @1x/@2x/@3x.
  • Optimization via pngcrush with iOS-specific settings.
  • Structuring Assets.xcassets with correct names and slots.
  • Audit of existing assets: find blurry, redundant, suboptimal ones.
  • Recommendations on format (PDF vs PNG) for each icon type.
  • Delivery includes Xcode Asset Catalog file, compressed PNG set, and written documentation.
  • Free training session on asset maintenance.
  • 30 days post-delivery support.

Timeline and Cost

Standard volume (20–50 elements) – from 4 hours to 1 day. Large projects with illustrations – up to 2 days. Price: from $150 for basic sets, $300 for standard, $500+ for complex. Fixing post-release bugs can save up to 60% of QA time. Order asset preparation – we’ll assess the scope within 4 hours. Get a consultation on Asset Catalog optimization. Our experience: 5+ years of iOS development, over 30 commercial projects. We guarantee no artifacts and pixel-perfect accuracy. We use only certified tools and Apple Human Interface Guidelines.

Contact us for a free estimate – we respond within 1 hour. Turnkey solution: we handle everything from Figma export to Xcode integration. Icons, buttons, backgrounds – all densities ready in 1 day. No hidden fees, full source files included.

Why is Native iOS Development the Best Choice for Complex Apps

The app crashes on cold start — EXC_BAD_ACCESS at the moment of initializing a singleton that accesses another singleton that hasn't been initialized yet. Or: a ViewController leaks memory because a closure captures self without [weak self], and that ViewController hangs in memory two transitions after the user left it. These are not hypothetical scenarios — they are the two most common classes of problems on iOS projects that come to us after another team.

We have been doing iOS development for over 5 years, delivered 40+ projects of varying complexity — from startups to enterprise solutions with millions of users. Each project undergoes 3 stages of Code Review, a custom set of UI tests (150+ test cases on average), and a mandatory run through Xcode Instruments before release.

Native iOS development with Swift means direct access to the platform. No middleware, no performance compromises, full control over what happens on every frame.

What Makes Native iOS Development on Swift the Choice for Enterprise Apps?

Native code guarantees compatibility with new Apple APIs on the day they are released, not after months of adaptation in cross-platform frameworks. For apps with latency-sensitive logic (financial terminals, medical monitors, AR navigation), this is critical. Swift with ARC and strict typing allows maintaining a crash-free rate of 99.9% with proper architecture.

SwiftUI or UIKit: What to Choose for Native iOS Development

By now, SwiftUI covers the vast majority of production tasks. But UIKit is not deprecated and will not disappear — Apple does not deprecate it but continues to add APIs. The real picture on large projects: a hybrid approach. SwiftUI for most screens, UIKit where SwiftUI hits limitations.

Which Scenarios Does SwiftUI Win Unconditionally

SwiftUI's declarative syntax reduces UI code by 3-5 times compared to UIKit. A settings screen with List, Toggle, Picker — that's 40 lines of SwiftUI versus 200 lines of UIKit with UITableViewDataSource delegates. Time savings on UI development reach 60%. Apple recommends starting new projects on SwiftUI (Human Interface Guidelines).

@State, @Binding, @ObservableObject (and with iOS 17, the @Observable macro) create a reactive link between data and UI without manual reloadData(). Changing a @State variable automatically redraws the affected part of the hierarchy. This works correctly if you understand how SwiftUI computes the diff — via Equatable and id in ForEach.

AsyncImage, NavigationStack with type-safe routing via NavigationPath, searchable, refreshable — these are ready-made patterns that UIKit requires implementing manually.

When UIKit Remains Necessary

UICollectionView with compositional layout and diffable data source — complex grids with different cell types, horizontal sections inside vertical scroll, dynamic cell sizes. SwiftUI LazyVGrid / LazyHGrid do not provide such control.

Custom transitions between screens. UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning — interactive pop gesture with partial progress, custom hero transition with precise frame control. SwiftUI matchedGeometryEffect covers some cases, but not all.

UITextView with TextKit 2. Rich text editor, custom attributes, custom rendering — TextKit 2 (available since iOS 16) switched to async layout, solving performance issues on long documents. SwiftUI TextEditor is a wrapper around UITextView without direct access to TextKit.

UIScrollView with custom behavior. scrollViewDidScroll, parallax effects, sticky headers with custom logic, pull-to-refresh with custom indicator. SwiftUI ScrollView with scrollPosition and onScrollGeometryChange (iOS 17) covers some cases, but not all.

How Do We Integrate SwiftUI and UIKit Step by Step

  1. Identify screens where SwiftUI gives maximum gain (lists, forms, settings) — usually 70-80% of screens.
  2. For performance-critical areas (complex collections, custom animations) leave UIKit.
  3. Use UIHostingController to embed SwiftUI views into UIKit navigation stack.
  4. For backward compatibility, wrap UIKit components via UIViewRepresentable.
  5. Coordinator pattern (UIKit) manages navigation at the flow level, screens are implemented in SwiftUI.

One pattern we use on projects: UIKit coordinator manages navigation, while the screens themselves are in SwiftUI. The coordinator creates a UIHostingController, passes ViewModel via initializer or @EnvironmentObject, and manages transitions. This gives clean separation: SwiftUI handles UI, Coordinator handles navigation.

How async/await and Combine Work Together

Before Swift 5.5, asynchronous code on iOS was built on Combine or callback chains. With the advent of async/await and Actor, concurrency has become part of the language. On new projects we use async/await as the primary tool for network calls and business logic, and Combine for reactive UI state binding.

// Correct — @MainActor guarantees UI updates on main thread
@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

    func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userService.fetch(id: id)
        } catch {
            // handle error
        }
    }
}

Combine remains indispensable for debouncing input, merging multiple Publishers (CombineLatest, Zip), and functional processing of value streams (map, flatMap, filter). In practice, 80% of projects use both approaches, choosing the tool for the task.

iOS App Architecture

MVVM — the basic pattern. ViewModel contains logic and @Published state, SwiftUI View subscribes via @ObservedObject or @StateObject. One rule: View knows nothing about URLSession, CoreData, UserDefaults.

Clean Architecture adds Repository and UseCase layers. UserRepository abstracts the data source (network vs cache). FetchUserUseCase contains business logic. UserViewModel calls UseCase and manages UI state.

TCA (The Composable Architecture) — a stricter pattern from Point-Free. State, Action, Reducer, Effect — everything explicit, testable, composable via Scope. Works well in large teams (5+ iOS developers) where predictability is important.

What's Included in iOS App Development

Stage Deliverables
Analysis and Design Technical specification, architectural diagram, technology stack selection
Development Code compliant with App Store Review Guidelines, backend integration (REST/GraphQL)
Testing Unit tests (XCTest, coverage >75%), UI tests (XCUITest, 150+ scenarios), load testing via Firebase Test Lab
Publication Developer account setup, code signing, submission to App Store Connect
Support 30-day warranty after release, updates for new iOS versions

Tools Without Which No Release Is Complete

Xcode Instruments. Time Profiler shows where CPU spends time. Allocations — memory leaks and excessive allocations. Leaks — objects that are not freed. Before every release — a mandatory run.

Firebase Crashlytics. Crash-free rate, grouping by stack trace, breadcrumbs of events leading to crash. Set up in 30 minutes, provides visibility across the entire device fleet. On our projects, average crash-free rate is 99.8%.

Fastlane match. Manage certificates and provisioning profiles via an encrypted git repository. Eliminates the 'it builds locally but not on CI' issue once and for all. Saves up to 4 hours per build when signing manually.

XCTest + XCUITest. Unit tests for ViewModel and UseCase, UI tests for critical flows (onboarding, payment, authorization). On average, code coverage is 75%.

Typical iOS Project Mistakes and Their Solutions
Problem Solution
Memory leak due to self capture in closure Use [weak self] in all handlers where self does not need to outlive the closure
Provisioning Profile conflicts Set up Fastlane match and store certificates in a separate repository
Slow app start due to synchronous singleton initialization Move initialization to first call or use lazy var
App Store rejection due to Section 4.2 (minimal functionality) Conduct a preliminary audit using the App Store Review Guidelines checklist

Process and Timelines

Complexity Estimated Timeline
MVP (5–8 screens, basic API) 6–10 weeks
Medium app (15–25 screens) 3–5 months
Complex (payments, AR, CoreML, custom UI) 5–9 months

Cost is calculated individually after analyzing the technical specification and design. Typically, the first 2 weeks are spent on design, after which we finalize the timeline and budget.

Order turnkey development — we will evaluate your project in 2 business days and propose the optimal architecture. Contact us to discuss your task: we guarantee code quality, compliance with App Store Review Guidelines, and experience with projects of any scale. Get a consultation — we will help you choose the right stack and avoid common mistakes at the start.