If u add a methods to existing frameworks via categories, convention says u should prefix those methods with something like your initials. e.g.
@interface UIFont (MySweetAdditionToThisExistingFramework)
If u choose not to perform this conventional step, you may inadvertently name your method identically to a private Apple one, resulting in your method being called in lieu of Apple’s perhaps causing your mac to catch on fire, or crash your program, or cause a inexplicable bug…
Furthermore, if u dodged that mine for now, Apple could at any time introduce a method that indeed shares the signature of yours causing your app to go haywire upon an iOS update.
When using Core Foundation, if a function name contains the word Create or Copy, u own the object and must balance it with a CFRelease(obj); function call, to free the memory.
On a more esoteric note, sooner or later u may work on code destined for versions of iOS that don’t support ARC. In those cases if u do not understand the naming conventions for memory management your app will likely crash one way or another (& it will be a hellacious experience figuring out why). Either through memory leaks or accessing bad memory via a dangling pointer. The convention is objects created by methods other than alloc and copy get sent autorelease before being returned and it is up to u to manually retain them if u need them after the pool gets flushed. If u get an object through alloc or copy u are required to release it or u leak.
So if u decide to go rogue on the naming conventions and return an object that is not autoreleased in a method u define that doesn’t have alloc or copy in its name, how would u know u need to release that object? It would take more than reading the method name, presumably. Of course u could adopt ur own naming system, but to what end?