Krzysztof Zabłocki:
There is much more you can do with [breakpoints], e.g. you can elevate your custom breakpoint to User Breakpoint and have them work in all your projects, why would you do that?
Because you can create symbolic breakpoint’s that execute code whenever a specific point is reached, e.g. UIApplicationMain[…]
See also this snippet to log x86_64 Objective-C methods calls and Xtrace.
KZLinkedConsole - adds ability to jump straight to the source code that logged an error
Unit test failures are another place Xcode could use some linking.
Debugging iOS LLDB Mac Programming Testing Xcode
William Gallagher interviews Ken Case:
Apple now provides iCloud, a service that amongst other things keeps apps in sync across many devices, yet the Omni Group ignore that in favor of its own alternative. That product has a better name -- it’s called OmniPresence -- but it is really duplicating what Apple is already doing. “Well, iCloud is really great when it works. I’ll put it that way,” says Case.
“When it doesn’t work, then customers blame us, but we have nothing we can do to try to fix their problems. When we shipped the first versions of all of our software on iOS, all of them supported WebDAV.” This was part of Apple’s predecessor to iCloud, and performed much the same job of syncing. “Well, of course we all know what happened: after they introduced iCloud, they turned off the WebDAV access, and suddenly everybody who was syncing through Apple’s once-supported service were upset because their Omni apps stopped syncing.
“So I guess there’s an element of once bitten, twice shy. If we then switched to Apple’s iCloud, then we would bitten again when the next thing comes along. I think it’s great that Apple does keep moving forward, but we need to make sure we can support our customers, and we couldn’t do it very well when we were building on top of services that could go away at any moment; that we didn’t have control over.”
Bug Business History iCloud iOS Mac NeXT OmniPresence The Omni Group
Daniel Jalkut (tweet):
A little over a year ago, I received a message from Apple that another developer had challenged my use of their trademark. Although I had been using the trademark myself for 7 years, they filed a trademark registration, and set to work demanding that I, and probably others, cease using the mark. I pushed back as long and as hard as I felt that I could without risking huge legal costs. I am confident that if I could justify the expense of defending the trademark, I would have prevailed because of my clear prior use of the mark. I could not, however, justify that cost. Hence the name change to Swish.
[…]
Before the trademark issue came to a head, I had built and submitted a version for Apple TV. […] Apple deemed the app too simplistic and suggested that I add more functionality.
It seems useful enough to me.
Apple TV iOS iOS App Legal tvOS App
Keith Harrison:
The rules for naming parameters in Swift functions and methods have changed for the better over the last few releases but still seem to cause confusion. Here is my quick summary updated for Swift 2.1.
Coming from Objective-C, I still think it feels a bit weird that the declaration and call site don’t match. In Swift declarations, we have external-space-internal-colon-type, whereas at the call site we have external-colon-value. In Objective-C, we have external-colon-(optional type)internal and external-colon-value, which makes sense because the value goes into the internal name. In Objective-C, the external name is always followed by a colon. In Swift, the external name is sometimes followed by a space and sometimes by a colon, and the colon is also used to specify the type. It’s a thorny problem because there is precedent in other languages for both uses of the colon.
Language Design Objective-C Programming Swift Programming Language
