Apple .NET Developer Interview Questions & Answers

At a high level, AirDrop should let nearby iOS and macOS devices find each other and transfer files securely. The main challenge is doing this without depending on the internet while still protecting user privacy. I would explain it in three flows: discovery, privacy and secure connection, then file transfer and recovery. BLE helps devices discover each other, peer-to-peer Wi-Fi carries the file, and the receiver controls acceptance. The trade-off is that range, battery use, and link quality can affect transfers.

The goal is to let two nearby Apple devices find each other and transfer files safely. The devices may be close together even when there is no internet connection. The difficult parts are finding the other device, deciding whether the receiver should be visible, creating a secure connection, and moving a file without losing progress. The diagram solves this with nearby discovery, privacy and trust checks, a secure peer-to-peer transfer path, and retry handling when the connection becomes weak or breaks.

1. Should the design support both iOS-to-macOS and macOS-to-iOS transfers?
2. Should nearby transfer work when both devices have no internet access?
3. Should large files support retry or resume after a broken connection?
4. Should same-account devices be allowed to accept transfers automatically?

I would start with Bluetooth Low Energy, or BLE, because it uses little power for nearby discovery. The sender advertises its presence and exchanges device information needed to find possible receivers. After discovery, the devices establish peer-to-peer Wi-Fi using AWDL. AWDL provides the nearby direct Wi-Fi path, so the transfer does not depend on the surrounding LAN or an internet connection.

The next step is deciding whether the receiver should appear and accept the request. The receiver can use visibility settings such as Everyone, Everyone for 10 Minutes, Contacts Only, or Receiving Off, as supported. The design also checks authenticated device identity and contact matching when applicable. The receiver normally accepts or declines the request. Same-account devices may auto-accept. Abuse Protection bounds repeated discovery and transfer attempts.

After approval, the devices create a secure authenticated connection over peer-to-peer Wi-Fi and AWDL. The file-transfer session is encrypted, which protects file data while it moves between devices. The diagram also shows a TLS-secured authenticated transfer channel. Nearby transfer does not need to upload file content to a cloud relay before the receiver gets it.

The sender exchanges file metadata first. The file is then chunked and streamed through the encrypted connection. The receiver validates the received data, completes verification, and saves the file to local storage. Both applications can show transfer progress. After success, the devices confirm completion, close connections, and clear temporary keys and state.

Nearby AirDrop works without internet because BLE and peer-to-peer Wi-Fi handle discovery and transport. If the connection breaks, the design can reconnect, resume, retry failed chunks, and notify the user if recovery fails. Chunk size can adapt when link quality changes. Large files can use more battery and may be throttled. Devices must stay within practical Bluetooth and peer-to-peer Wi-Fi range for nearby transfer. On supported systems, an already started transfer may continue over the internet after the devices leave nearby radio range.

At a high level, the goal is to find an offline device without exposing the owner or finder. The main challenge is sharing a useful location while keeping identifiers temporary and location reports encrypted. I would explain three flows: the lost device broadcasts a rotating identifier, nearby finder devices relay encrypted location reports, and the owner later retrieves and decrypts matching reports locally. The main trade-off is privacy versus freshness because finding depends on nearby Apple devices becoming online.

The goal is to help an owner find a lost device even when that device has no internet connection. The difficult part is privacy. Nearby devices must help report its location without learning who owns it. Apple services should also avoid receiving the location in readable form. The diagram solves this with rotating identifiers, encrypted location reports, anonymous forwarding, and owner-side decryption. The flow starts at the lost device, passes through nearby finder devices and Apple services, and ends inside the owner’s Find My app.

1. How accurate does the reported location need to be?
2. How long should encrypted location reports be kept?
3. How quickly should a newly reported location become available?

I would start with the setup that happens while the device is online. During Enrollment, the owner signs in to Find My. The device is registered and keys are provisioned. The RID seed and rotation schedule are also prepared.

When the device becomes offline, it generates a Rotating Identifier, or RID. The RID changes periodically. This prevents passive observers from following one stable beacon over time. The lost device broadcasts the RID using Bluetooth Low Energy, or BLE. This step needs neither internet access nor GPS on the lost device.

A Nearby Finder Device receives the RID over BLE. It gets a coarse location using GPS or Wi-Fi. It then creates an encrypted location report and uploads it over HTTPS.

The finder device does not learn the lost device owner’s identity. It only helps transport the rotating identifier and encrypted location information into the network.

The Apple Relay Network receives the encrypted report. It validates the report, applies rate limits, removes duplicates, and strips IP and device metadata. It then forwards the report toward Find My Ingestion.

The Find My Ingestion Service receives the event over internal mTLS. It validates the report format and cryptographic integrity. It stores the encrypted location payload without decrypting it. It also indexes the encrypted report by rotating identifier so the owner can retrieve matching reports later.

The Data Stores keep Device State, Location Reports, and Public Registration Metadata. The Location Reports Store contains the encrypted report blob, rotating identifier, timestamp, and TTL. TTL means the stored report is automatically removed after its allowed lifetime.

The Owner Find My Apps authenticate the owner and query expected rotating identifiers. The Data Stores return matching Encrypted Location Reports. The owner app decrypts those reports locally with the owner-held key. It can then show the last-known location.

The Identity & Key Service registers public key metadata and authenticates owner access to encrypted reports. It never stores the owner’s private decryption keys or RID master secrets.

External traffic uses TLS, while services use mTLS internally. Encrypted reports include cryptographic integrity protection. Rate limiting, anomaly detection, abuse mitigation, TTL-based retention, and automatic purging reduce misuse and unnecessary stored data.

The main limitation is freshness. A nearby Apple device must hear the BLE beacon and become online before a new report reaches the owner. Location is also approximate for privacy, and storing many encrypted reports creates storage and compute cost.

At a high level, this system lets users delete photos without losing them immediately. The main challenge is keeping the 30-day recovery window correct across devices while freeing storage when policy allows it. I would explain three flows: soft delete and restore, iCloud sync, and permanent purge. The .NET service keeps deletion metadata, leaves media in encrypted object storage, and uses background workers for expiry, sync, and quota checks. The trade-off is extra storage and background work during recovery.

The goal is to let users remove photos from their normal library without destroying them immediately. Deleted items stay recoverable for 30 days. A restore must make the item visible again, while an expired or explicitly purged item can be removed permanently. The hard part is keeping the deletion state, expiry time, original media, and the user's other devices consistent enough to give predictable behavior. The diagram organizes this into the client request path, stored deletion state, background workers, iCloud sync, and the low-storage purge path.

1. Should every deleted item normally have the same 30-day recovery window?
2. Can the user permanently delete an item before the recovery window ends?
3. Can policy shorten recovery for local-only items when storage is critically low?
4. How quickly should deletes and restores appear on the user's other devices?

I would start with the Photos App actions shown in the diagram. A user can delete an item, open Recently Deleted, restore an item, or permanently delete it. The app sends HTTPS JSON requests through the edge layer. OAuth 2.0 or device authentication identifies the caller. Authorization checks scopes and access rules. Input validation and rate limiting protect the service before the request reaches the ASP.NET Core Photos Service API.

For a normal delete, DeleteController uses DeleteService to perform a soft delete. Soft delete means the item is marked deleted without removing the original media. The Primary Metadata Store records fields such as IsDeleted, DeletedAt, and ExpiresAt. It also keeps a DeletionRecord with the item, deletion time, expiry time, and purge state. The encrypted photo or video remains in Object Storage.

RecentlyDeletedController reads the recoverable items. RestoreController uses RecoveryWindowService to check whether recovery is still allowed. A successful restore clears the deleted state, removes the deletion record, and returns the item to the normal library.

The lifecycle is Active, Soft Deleted, In Recently Deleted, Expired, and Permanently Purged. A normal soft delete sets ExpiresAt to DeletedAt plus 30 days. PurgeWorker runs daily and permanently removes items whose ExpiresAt is at or before the current time. PermanentlyDeleteController also handles an explicit permanent-delete request. Delete, restore, and purge operations are designed to be safe when the same operation is repeated.

The iCloudSyncService and continuous iCloudSyncWorker carry deletion and restore state across the user's devices. The iCloud / Sync Metadata Store keeps cloud deletion state, expiry information, and device data. Other Photos App devices use iCloud push and pull to receive changes, update the local library, and update Recently Deleted.

The Local / Distributed Cache can keep the Recently Deleted list, per-user counts, and recovery-window data. AuditService records deletion, restore, and purge events in the Audit / Event Store. MetricsWorker emits operational signals.

QuotaService and the continuous QuotaEnforcer watch storage usage and policy. The low-storage path can be triggered by device low storage, an enabled Optimize Storage setting, and quota enforcement. It can immediately purge items whose ExpiresAt is already at or before the current time. The diagram keeps the minimum 30-day recovery rule unless policy allows a shorter period for local-only items.

Media is encrypted at rest and protected by TLS in transit. User ownership and access controls protect private data. Multiple .NET service replicas improve availability. The main trade-off is that recoverability costs storage, metadata, sync work, and background processing until purge is allowed.

At a high level, Swift makes reference ownership safer than manual retain-release. The main challenge is keeping class instances alive only while something owns them, without creating leaks. I would explain it in three parts: ARC ownership rules, value versus reference types, and copy-on-write. ARC removes most manual retain and release calls, but strong reference cycles can still leak. Swift handles those cycles with weak or unowned references. The trade-off is safer memory management, but developers still need to design ownership correctly.

The goal is to understand how Swift manages memory without making developers manually balance every retain and release call. Manual retain-release puts that work on the programmer, so a missing release can leak memory and an extra release can destroy an object too early. Swift moves most of this work into ARC. The remaining challenge is ownership. Developers still need to know which references should keep an object alive, how cycles happen, and why value types behave differently from class references. Copy-on-write then shows how Swift keeps value semantics efficient.

1. Should I compare Swift ARC mainly with Objective-C style manual retain-release?
2. Should I explain both weak and unowned references when discussing retain cycles?
3. Should I cover copy-on-write using standard value types such as Array, Dictionary, Set, and String?

I would start with the older model because it makes ARC easier to understand. Under manual retain-release, code explicitly calls retain when another owner needs an object. That increases its reference count. Code later calls release to decrease the count.

When the count reaches zero, the object is destroyed. The danger is that every retain must be balanced correctly. Too many releases can destroy an object too early. Missing a release can leave an unused object in memory.

Next, I would explain ARC, which means Automatic Reference Counting. Swift manages the reference-counting operations needed for class instances automatically. A strong reference keeps a class instance alive.

As strong references are created and removed, ARC tracks the object's ownership. When no strong references remain, Swift deinitializes the instance automatically. This removes most manual retain and release work. The developer still defines the ownership relationships that ARC follows.

Strong is the normal reference type. A strong reference owns the object and keeps it alive. Weak and unowned references do not keep the referenced object alive.

A weak reference is optional and becomes nil when the referenced object is deallocated. An unowned reference is used when the program expects the referenced object to remain alive whenever that reference is accessed. Accessing an unowned reference after its object has been deallocated is unsafe, so that lifetime rule must really hold.

A retain cycle happens when class instances keep each other alive with strong references. For example, A can strongly reference B while B strongly references A. Neither reference count reaches zero, so ARC cannot deallocate either instance.

The normal fix is to make a back-reference weak when it may become nil. Unowned can be used when the lifetime relationship guarantees that the referenced object must outlive that reference. Delegates, parent relationships, and similar back-references are common places to check for cycles.

Structs and enums are value types. Assignment gives independent value semantics, so changing one value does not change another copy. Classes are reference types. Multiple variables can point to the same class instance, so a change through one reference is visible through the others.

Copy-on-write makes large value types cheaper to copy. For example, two Array values can initially share the same backing buffer. A mutation checks whether that storage is shared. If it is shared, Swift gives the value being changed its own buffer before applying the mutation. This keeps value semantics while avoiding unnecessary copying. Standard types such as Array, Dictionary, Set, and String use this idea. In practice, I would also use Instruments when I need to find leaks or unexpected allocations.

At a high level, I need a clean way to consume continuous location updates. The main challenge is handling cancellation, slow consumers, and stream operations without making the code hard to manage. I would compare Swift Concurrency and Combine across cancellation, backpressure, and operator support. For new code, I would pick Swift Concurrency with AsyncSequence. AsyncStream gives simple async/await integration and bounded buffering. Combine remains strong when I need demand-aware publishers or an existing, operator-heavy Combine pipeline.

The goal is to handle a continuous stream of location changes and deliver useful updates to the application. The difficult part is managing a stream that may run for a long time. We must stop work when the consumer disappears, avoid unlimited buffering when updates arrive quickly, and transform values when needed. The diagram compares two choices. Swift Concurrency uses AsyncSequence with AsyncStream. Combine uses a Publisher. I would compare cancellation, buffering and backpressure, and operator support before choosing one.

1. Is this new code, or does the application already use Combine heavily?
2. Does the consumer need every location update, or mainly the newest location?
3. Do we need complex stream operations such as throttle, debounce, or combining publishers?

I would start with where the updates come from. Location Source represents GPS, Wi-Fi, or cellular events. CLLocationManager receives those events and exposes delegate callbacks.

The manager can use startUpdatingLocation(), startUpdatingHeading(), or startMonitoringSignificantLocationChanges(). Those callbacks feed the stream abstraction in the middle of the diagram.

For new code, I would choose Swift Concurrency with AsyncSequence. The diagram wraps the delegate callbacks as locationUpdates() returning AsyncStream<CLLocation>.

The continuation yields each location value. A consumer can read the stream with a for await loop. This fits naturally with async/await and structured concurrency, where asynchronous work follows the lifetime of the task that owns it.

Cancellation still needs cleanup. Task cancellation can end iteration, but the stream should use onTermination or cancellation cleanup to call stopUpdatingLocation(). This prevents CLLocationManager from continuing after the consumer is gone.

AsyncStream can use bufferingNewest(n) or bufferingOldest(n). These policies bound the number of buffered elements and can drop values when the consumer is slower.

This is not demand-based backpressure. The producer is not automatically slowed by downstream demand. The policy decides which values remain buffered while production continues.

Combine supports downstream demand through Subscribers.Demand when the publisher honors that demand. Operators such as buffer, throttle, and debounce can further shape delivery.

Swift Concurrency supports operations such as map, compactMap, filter, and reduce. AsyncAlgorithms can provide more sequence operations, and custom transforms can be written around await loops.

Combine has a mature operator set. The diagram shows map, filter, removeDuplicates, throttle, debounce, flatMap, switchToLatest, scan, and share. That makes Combine attractive when an application already has complex Combine pipelines.

The location stream can update a Map View or UI. It can also drive business logic such as geofencing, trip tracking, analytics, and ETA calculation.

The diagram shows optional side paths for Local Storage, Background Tasks, Remote Services, Notifications, and Observability. These are supporting paths, not requirements for every location update.

For lifecycle handling, Swift Concurrency cancels the task and performs cleanup. Combine stores AnyCancellable values in Set<AnyCancellable> and cancels them when the consumer disappears. The main trade-off is simple. Swift Concurrency gives a cleaner async/await model and structured cancellation. Combine gives mature operators and subscriber demand. For new code, I would choose Swift Concurrency unless the application already relies heavily on Combine.

At a high level, Array and Set solve different collection needs in Swift. The main choice is whether order, duplicates, or fast membership checks matter most. I would compare them in three parts: ordering and duplicates, lookup cost, and type requirements. An Array keeps insertion order, allows duplicates, and supports O(1) index access. A Set stores unique values and gives average O(1) membership checks, but its order is not guaranteed. The trade-off is that Set elements must conform to Hashable.

This question asks us to choose the right Swift collection for the job. An Array is useful when values need a known order or when duplicates are meaningful. A Set is useful when values must be unique or when we often need to check whether something exists. The main challenge is understanding which behavior matters more for the program. I would explain the choice by comparing order, duplicates, lookup cost, and the requirement that Set elements support Hashable. Then I would show when each collection is the better fit.

1. Do we need to preserve the order of the values?
2. Are duplicate values meaningful, or should each value appear once?
3. Will we frequently check whether a value already exists?
4. Will the collection store custom types?

I would start by saying that Array is ordered, while Set has no guaranteed order. An Array keeps elements in insertion order. Each element also has a position, so we can access it using an integer index. Reading a known Array index is O(1), which means the access cost stays roughly constant as the collection grows. A Set does not provide integer-based indexing. Its iteration order can change, so code should not depend on that order.

Next, I would explain that an Array allows duplicate values. For example, [1, 2, 2, 3, 4] is a valid Array. A Set stores only unique values. If 2 is already in the Set, inserting 2 again does not add another copy. This makes Set a natural choice when duplicate values should be removed or prevented.

The lookup difference is important when the collection becomes large. Searching an Array by value is O(n), because Swift may need to examine many elements. A Set uses hashing to find values quickly. Its search, insert, and remove operations are average O(1). In rare cases with poor hash distribution, the cost can reach O(n). That is why Set is useful when fast membership checks matter more than order.

A Set requires its element type to conform to Hashable. Hashable lets Swift calculate a hash value that helps the Set locate values and keep them unique. Common types such as Int and String already support it. The diagram also shows a custom User struct conforming to Hashable. When its stored properties support Hashable, Swift can synthesize the conformance automatically.

I would use Array when order matters, duplicates are allowed, or I need position-based access. I would use Set when I need unique values or frequent membership checks and order does not matter. Swift can convert an Array to a Set with Set(array) and convert back with Array(set). The important trade-off is that converting to a Set removes duplicates and does not preserve a guaranteed iteration order.

At a high level, the goal is to make scrolling stay smooth while cells appear and update. The main challenge is finding which work misses the frame budget instead of guessing. I would break the diagnosis into three parts: reproduce the jitter, measure it with Instruments, then fix the measured bottleneck and profile again. Common fixes simplify cell and layout work, move image decoding off the main thread, reduce overdraw, and avoid full reloads. The downside is more background-work and cache management.

The goal is to find why a table or collection view cannot draw some frames quickly enough. The difficult part is that many different problems can look like the same scroll stutter. Heavy cell setup, layout work, image decoding, extra drawing, memory churn, or synchronous work can all delay the next frame. The diagram uses an evidence-first process. Reproduce the problem on a real device, measure it, identify the bottleneck, confirm it with evidence, apply the matching fix, and record again to prove that scrolling improved.

1. Does the jitter happen on real devices, or only in the Simulator?
2. Is it worse when images appear or complex cells become visible?
3. Are we targeting about 60 FPS and frames below 16.7 ms?

I would first make the problem repeatable. I would use a real device with a Release build and record a short scrolling trace. I would note the device, content size, and cell type. I would also use Color Blended Layers or Slow Animations when they help expose rendering problems.

Next, I would profile the actual hitch. Core Animation shows FPS, long frames, and rendering problems. Time Profiler shows main-thread CPU hotspots and useful backtraces. Allocations shows object churn during scrolling. I would also inspect memory for retain cycles when memory growth is part of the symptom.

Then I would connect the measurements to the exact scroll hitch. I would check for too many layout passes, expensive cell work, image decoding on the main thread, overdraw, or synchronous disk and network work. Allocation spikes can also reveal repeated temporary objects. I would fix only a cause that the trace supports.

For cells, I would keep cellForRowAt or cellForItemAt lightweight. Heavy data or image preparation should happen before the cell needs it. I would reuse content views and use UIContentConfiguration with updateConfiguration(using:) where it fits.

For layout, I would create constraints once and update constants. I would set estimatedRowHeight or estimatedItemSize correctly and avoid layoutIfNeeded during scrolling. Self-sizing cells need complete, unambiguous constraints.

For images, I would load and decode them away from the main thread. I would downsample them to the displayed size, cache completed images, show a placeholder immediately, prefetch when useful, and cancel in-flight work when a reused cell no longer needs it.

If overdraw is expensive, I would remove unnecessary backgrounds, transparency, masks, and shadow combinations. Opaque views can reduce blending work. For data changes, I would prefer incremental Diffable Data Source updates and batching instead of full reloads. Background preparation can use OperationQueue or Task priorities, while UI changes stay on the main actor. I would also throttle background work so it does not consume all available CPU.

Finally, I would record the same scroll again. I would look for about 60 FPS, frame times below roughly 16.7 ms, lower main-thread CPU, fewer allocations, and stable memory. I would test multiple real devices and add performance tests or signposts for regressions. The key rule is simple: measure, fix the proven cause, and measure again.