Swapping the `objectAtIndex:` method of `__NSArrayM` using `method_exchangeImplementations` will lead to continuous memory growth.

What you’re doing is deeply unsupported, and I strongly recommend that you stop doing it.

In general, Apple doesn’t support folks swizzling methods on Apple’s classes. And in this case you’re swizzling methods on a class, __NSArrayM, that’s an implementation detail. It’s never good to rely on implementation details because they could change at any time, and that would break your code.

If you explain more about your high-level goal, I may be able to suggest an alternative path forward.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your prompt reply and professional advice! I fully understand the risks of directly manipulating the implementation details of private classes, which indeed pose potential issues for code maintenance. The reason I adopted method swizzling is to catch and handle NSRangeException (array out-of-bounds) crashes that commonly occur in iOS apps. Such problems frequently arise in complex business scenarios and severely impact the user experience. For example:

• Index out-of-bounds caused by changes in dynamically loaded JSON data formats
• Inconsistent data states when arrays are operated on by multiple threads
• Desynchronization between data sources and view updates during complex UI rendering

By swapping methods like objectAtIndex:, we’ve implemented unified interception of boundary checks, recording context information and returning default values before an out-of-bounds error occurs. This has effectively reduced the crash rate. However, as you noted, this solution does carry compatibility risks.

I would greatly appreciate your guidance on the following alternative approaches:

1. Are there any public APIs that can achieve similar array out-of-bounds protection? (e.g., NSProxy subclasses or custom container classes)
2. For dynamic data, are there recommended validation frameworks or best practices?
3. Does Apple internally have tools or suggestions for detecting/preventing such issues?

Additional Question About Memory Growth:

I've noticed an unexpected memory issue in my test app. When I continuously tap the screen after launch, the memory usage keeps increasing steadily. This happens even when:

• The taps only trigger simple array lookups (no new data is loaded)
• I've verified no new objects are retained in my code
• Instruments shows steady growth in __NSArrayM and __NSCFString instances

Could method swizzling on __NSArrayM interfere with ARC or the autorelease pool? Or might there be hidden retain cycles caused by overriding system methods? I'd appreciate any insights on diagnosing this.

We highly value code quality and compliance, and we look forward to finding a more elegant solution under your guidance. If further details are needed, I’m happy to provide reproduction cases for specific scenarios.

Thank you again for your assistance!