Re: Thoughts on Cocoa

[Glenn L. Austin via Cocoa-dev]

> On Oct 11, 2019, at 11:17 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
>> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev 
>>  wrote:
>> and the maturity of the compilers available, there is any need for Swift. 
>> But there it is. Or, there they are. Perhaps this is the way the younger 
>> generation overtthrows the older? Or not, but I’m pretty sure there is no 
>> compelling business argument for it.
> 
> 
> Holy hell, Swift isn’t perfect, but I’d rather use it over C++ a thousand 
> times over.


It feels to me that Swift is to LLVM as C++ was to gcc.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

—Jens 

> On Oct 11, 2019, at 3:32 PM, tblenko--- via Cocoa-dev 
>  wrote:
> 
> I attended a public (technical) talk in Town Hall (I think it’s called) at 
> Apple shortly before or after I went to work there. It would have been around 
> 2000-2001.
> 
> The speaker’s message was that the future of the desktop was Java the 
> speaker was the manager of the compiler group responsible for Java and 
> Objective-C — and had been going back to early NeXT days. So one had to 
> conclude that he was committed to the course he described. People tried to 
> ask about Objective-C (vs. Java) and he said that Objective-C was done, he 
> clearly didn’t want to talk about that.

That was the feeling at NeXT/Apple at the time of the merger, but it had 
fizzled out by 2000. Performance of Java, especially app launch time, wasn’t 
good enough. That sounds like Steve Naroff talking (great guy), but probably no 
later than 1999.

 (I was working on Java at Apple during that time. I was a huge Java zealot 
early on, but by 2000 I’d decided it wasn’t good for desktop apps, and embraced 
Obj-C.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[조성빈 via Cocoa-dev]

> 2019. 10. 12. 오후 7:52, Jean-Daniel  작성:
> 
> 
>>> Le 12 oct. 2019 à 03:07, 조성빈 via Cocoa-dev  a 
>>> écrit :
>>> 
>>> 
>>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>>>  작성:
>>> 
>>> 
 On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
  wrote:
 
>> I know this is the Cocoa devs list... but why not make a website?
>> It would be easier to develop, completely crossplatform, no app store
>> complications, you would be in total control of your stack, etc.
 
 QuickBooks has gone that route.  They still grudgingly sell desktop apps,
 but really push people towards their cloud version.  Besides all the
 benefits you mention, it's a steady monthly income.  Hence why Microsoft
 and Adobe are also going that route.  Apple too.
>>> 
>>> If I understand this correctly.
>>> 
>>> Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions 
>>> of desktops apps that run in a web browser along with a subscription 
>>> service.
>>> 
>>> Apple iWork web apps (Pages, Numbers, Keynote) are feature complete 
>>> versions of desktop and mobile apps that run in a web browser. Apple has 
>>> never released the details of how they do this.
>> 
>> Microsoft Office & Apple iWork web apps could be complex due to 
>> compatibility with the offline ones, and that they have a feature set that 
>> only has steadily expanded for a ten to twenty years.
>> They also need to have their app integrated with their other services.
>> 
>>> Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for 
>>> desktop and mobile with cloud based storage and a subscription service. 
>>> They are not cross-platform browser based web apps.
>>> 
>>> None but the biggest of companies can do this.
>> 
>> That’s not true, web apps aren’t really complex if you get to use the npm 
>> ecosystem. There are high quality libraries that do much of the heavy 
>> lifting, so writing ones usually are wiring glue code between the libraries.
> 
> I’m not quite sure what your definition of complex is, but on my side, I 
> consider that an app that use hundred (if not thousand) of dependencies that 
> have to be review

To be optimal, all of the npm dependencies should be reviewed... but I’ve never 
seen a codebase that reviews all of its deps.
Mostly, if it is done, it’s usually the direct ones, and to be honest, it 
really doesn’t matter if you want to get things done. 

I’m pretty sure most Cocoa codebases don’t review its cocoapods deps as well.

> and properly managed to avoid conflict

I’ve never seen npm dependencies conflict. 

> and can disappear without notice and break your app,

After the left-pad fiasco, packages with dependents cannot be removed without 
npm’s consent.

> is a complex system.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 12 oct. 2019 à 03:07, 조성빈 via Cocoa-dev  a 
> écrit :
> 
>> 
>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>>  작성:
>> 
>> 
>>> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>>>  wrote:
>>> 
> I know this is the Cocoa devs list... but why not make a website?
> It would be easier to develop, completely crossplatform, no app store
> complications, you would be in total control of your stack, etc.
>>> 
>>> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
>>> but really push people towards their cloud version.  Besides all the
>>> benefits you mention, it's a steady monthly income.  Hence why Microsoft
>>> and Adobe are also going that route.  Apple too.
>> 
>> If I understand this correctly.
>> 
>> Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions 
>> of desktops apps that run in a web browser along with a subscription service.
>> 
>> Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions 
>> of desktop and mobile apps that run in a web browser. Apple has never 
>> released the details of how they do this.
> 
> Microsoft Office & Apple iWork web apps could be complex due to compatibility 
> with the offline ones, and that they have a feature set that only has 
> steadily expanded for a ten to twenty years.
> They also need to have their app integrated with their other services.
> 
>> Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for 
>> desktop and mobile with cloud based storage and a subscription service. They 
>> are not cross-platform browser based web apps.
>> 
>> None but the biggest of companies can do this.
> 
> That’s not true, web apps aren’t really complex if you get to use the npm 
> ecosystem. There are high quality libraries that do much of the heavy 
> lifting, so writing ones usually are wiring glue code between the libraries.

I’m not quite sure what your definition of complex is, but on my side, I 
consider that an app that use hundred (if not thousand) of dependencies that 
have to be review and properly managed to avoid conflict and can disappear 
without notice and break your app, is a complex system.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Charles Srstka via Cocoa-dev]

> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev 
>  wrote:
> 
> Me, I still don’t understand why, given the long history of support at 
> Apple/NeXT for C++

…what?

> and the maturity of the compilers available, there is any need for Swift. But 
> there it is. Or, there they are. Perhaps this is the way the younger 
> generation overtthrows the older? Or not, but I’m pretty sure there is no 
> compelling business argument for it.


Holy hell, Swift isn’t perfect, but I’d rather use it over C++ a thousand times 
over.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 7:07 PM, 조성빈  wrote:
> 
>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>>  작성:
>> 
>> None but the biggest of companies can do this.
> 
> That’s not true, web apps aren’t really complex if you get to use the npm 
> ecosystem. There are high quality libraries that do much of the heavy 
> lifting, so writing ones usually are wiring glue code between the libraries.

Multiple versions of an app possibly consisting of a browser base web app along 
with a high performance and convienent native desktop app (possibly native on 
Mac and Windows) and a native mobile app (possibly native on iOS and Android), 
a file based format for offline storage (native on Mac and Windows) and a cloud 
based format for online storage and colloraboration all working seamlessly 
together. Unless I am mistaken Adobe and Microsoft approach this with Creative 
Cloud and Office 360 apps.

None but the biggest of companies can to this.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[조성빈 via Cocoa-dev]

> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>  작성:
> 
> 
>> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
 I know this is the Cocoa devs list... but why not make a website?
 It would be easier to develop, completely crossplatform, no app store
 complications, you would be in total control of your stack, etc.
>> 
>> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
>> but really push people towards their cloud version.  Besides all the
>> benefits you mention, it's a steady monthly income.  Hence why Microsoft
>> and Adobe are also going that route.  Apple too.
> 
> If I understand this correctly.
> 
> Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions 
> of desktops apps that run in a web browser along with a subscription service.
> 
> Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions 
> of desktop and mobile apps that run in a web browser. Apple has never 
> released the details of how they do this.

Microsoft Office & Apple iWork web apps could be complex due to compatibility 
with the offline ones, and that they have a feature set that only has steadily 
expanded for a ten to twenty years.
They also need to have their app integrated with their other services.

> Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for 
> desktop and mobile with cloud based storage and a subscription service. They 
> are not cross-platform browser based web apps.
> 
> None but the biggest of companies can do this.

That’s not true, web apps aren’t really complex if you get to use the npm 
ecosystem. There are high quality libraries that do much of the heavy lifting, 
so writing ones usually are wiring glue code between the libraries.

> One alternative for native desktop apps is a Box Integration.
> 
> https://support.apple.com/en-us/HT207876
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/pcr910303%40icloud.com
> 
> This email sent to pcr910...@icloud.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
>>> I know this is the Cocoa devs list... but why not make a website?
>>> It would be easier to develop, completely crossplatform, no app store
>>> complications, you would be in total control of your stack, etc.
> 
> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
> but really push people towards their cloud version.  Besides all the
> benefits you mention, it's a steady monthly income.  Hence why Microsoft
> and Adobe are also going that route.  Apple too.

If I understand this correctly.

Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions of 
desktops apps that run in a web browser along with a subscription service.

Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions of 
desktop and mobile apps that run in a web browser. Apple has never released the 
details of how they do this.

Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for desktop 
and mobile with cloud based storage and a subscription service. They are not 
cross-platform browser based web apps.

None but the biggest of companies can do this.

One alternative for native desktop apps is a Box Integration.

https://support.apple.com/en-us/HT207876

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Gary L. Wade via Cocoa-dev]

The hard thing to make work best with NSComboBox is what to have its data 
source return when a user enters something not available in the list, so there 
is that decision to make, especially if your list is very sparse. You could 
also just use a pop up button that allows both mouse selection and text 
selection of a menu item when opened.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 10:10 AM, Turtle Creek Software  
> wrote:
> 
> NSComboBox was almost perfect, but we needed it to only allow existing items.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 4:46 PM, Jens Alfke  wrote:
> 
>> On Oct 11, 2019, at 12:22 PM, Richard Charles  wrote:
>> 
>> A second choice "Cross-platform Cocoa App" would be great for the small 
>> developer who’s focus is on business applications. All whole world doesn’t 
>> revolve around games.
> 
> https://developer.apple.com/xcode/swiftui/
> https://developer.apple.com/mac-catalyst/

What I meant to say was Cross-platform as in Microsoft Windows.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 12:22 PM, Richard Charles  wrote:
> 
> A second choice "Cross-platform Cocoa App" would be great for the small 
> developer who’s focus is on business applications. All whole world doesn’t 
> revolve around games.

https://developer.apple.com/xcode/swiftui/
https://developer.apple.com/mac-catalyst/

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[tblenko--- via Cocoa-dev]

There’s a (short, I think) chapter missing from this story. I attended a public 
(technical) talk in Town Hall (I think it’s called) at Apple shortly before or 
after I went to work there. It would have been around 2000-2001.

The speaker’s message was that the future of the desktop was Java. A pretty big 
surprise and unwelcome news for those of us who saw Apple as the future of 
Objective-C and the NeXTStep lineage rather than the other way around. As the 
talk went on, it came out that the speaker was the manager of the compiler 
group responsible for Java and Objective-C — and had been going back to early 
NeXT days. So one had to conclude that he was committed to the course he 
described. People tried to ask about Objective-C (vs. Java) and he said that 
Objective-C was done, he clearly didn’t want to talk about that.

This before the public release of Mac OS X 10.0.

Another effort that sank in the deep blue sea.

I think one has to assume that technology strategy at Apple is less disciplined 
by the business side than at companies like IBM, Microsoft, Intel, Oracle, etc. 
And within Apple, there is a certain amount of chaos within Engineering that 
gets exposed from time to time. I think they might feel that’s a good thing. If 
you’re thinking like a business person, you should accept this as a given and 
make your decisions accordingly. If you’re thinking like a person who likes the 
technology, you may or may not reach the same conclusions. But I don’t think 
you’re going to change the way Apple does things.

Me, I still don’t understand why, given the long history of support at 
Apple/NeXT for C++ and the maturity of the compilers available, there is any 
need for Swift. But there it is. Or, there they are. Perhaps this is the way 
the younger generation overtthrows the older? Or not, but I’m pretty sure there 
is no compelling business argument for it.

Tom


> On Oct 11, 2019, at 2:54 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
>> On Oct 11, 2019, at 12:44 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>>>  wrote:
>>> 
>>> Just a guess but perhaps management had an awakening when they found the 
>>> time and effort expended to write the next even better version of Finder in 
>>> Carbon was substantially more difficult and costly that the prior Cocoa 
>>> version.
>> 
>> The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. 
>> The development versions had a NeXT file manager with a Mac UI skin, but 
>> before release that was replaced with a Carbon-ized port of (a subset of) 
>> the MacOS 9 Finder. That Finder lived on for a few years before being 
>> replaced by a new rewritten Cocoa version.
>> 
>> —Jens
> 
> The NeXT/Rhapsody file manager was what I was referring to.
> 
> As for the 10.0 Finder, I’m sure it shared code with the OS 9 finder, but it 
> was an essentially new app based on PowerPlant (which the OS 9 Finder, to the 
> best of my knowledge, was not). It did not feel much like the OS 9 Finder, 
> and it was missing a lot of basic functionality that the OS 9 Finder had had, 
> much of which was gradually reintroduced over the years. The Cocoa rewrite of 
> the Finder did not appear until Snow Leopard was released in 2009. Notably, 
> the Finder was still Carbon when Apple suddenly out of nowhere (again, from 
> the perspective of an outsider) dropped the previously promised 64-bit Carbon 
> support in 2007.
> 
> As for the Dock, there was no OS 9 analogue to that at all, so the only 
> conclusion can be that it was rewritten in Carbon from the ground up, when a 
> Cocoa one had been previously available. This is difficult to explain other 
> than as a statement of confidence in Carbon.
> 
> Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/blenko%40martingalesystems.com
> 
> This email sent to ble...@martingalesystems.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Alex Zavatone via Cocoa-dev]

It does the useful thing on 10.15.  I just had to add some scene code to our 
iOS app that had availability indicators around the methods indicating to use 
them on iOS 13 and greater.

Sent from my iPhone

> On Oct 9, 2019, at 1:39 PM, Aandi Inston via Cocoa-dev 
>  wrote:
> 
> " . Cocoa is part of the OS, and changes one very OS release. "
> 
> This reminds me of a question which pops up for me every few years in
> development. I can't call to mind the last
> specific details, but it will happen again.
> Let's create an imaginary problem:
> * Apple add a new class behaviour to Cocoa in macOS 10.15. We'll suppose
> they add [NSApplication doUsefulThing]
> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get
> a compile-time warning. Still, I'd
> really like to do the useful thing anyway, and without changing the SDK for
> whatever reason.
> * I add a check for actual OS version, so I am very sure not try to call
> [NSApplication doUsefulThing]
> unless the OS is 10.15 or later.
> * But what happens if it runs in 10.15? Does it actually do the useful
> thing?
> Are the Cocoa methods entirely dynamically loaded/provided by the live OS?
> Or does anything get statically linked,
> flagged, is the binary's SDK version checked or is there anything else that
> will prevent this call doing the
> useful thing?
> 
> Thanks in advance!
> 
> On Wed, 9 Oct 2019 at 18:42, Jens Alfke via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> 
>> 
>> 
>>> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>>> 
>>> Why is Cocoa source code hidden?
>> 
>> So, take this as opinions of someone who worked at Apple, on [among other
>> things] Mac OS X apps from 2000-2007.
>> 
>> (a) It's part of Apple's crown jewels and seen as a competitive advantage.
>> (b) It calls all sorts of internal APIs of lower-level components like the
>> WindowServer, and Apple doesn't want to expose those APIs because they're
>> undocumented, easily misused, hard to support, subject to change at any
>> moment, etc.
>> (c) If developers look at the source code they'll be tempted to make use
>> of undocumented behaviors, private methods, etc. which makes their apps
>> much more likely to break in future OS versions. (This already does happen,
>> to an extent, but with source code it would be much more pervasive, given
>> the dynamic nature of Obj-C and how easy it is to call internal methods or
>> even patch system classes.)
>> (d) Internal source code tends to have comments and identifiers that refer
>> to internal code names, canceled projects, and other stuff that shouldn't
>> be made public. Sanitizing this is a pain.
>> (e) Apple obviously works on lots of features that remain secret for
>> months or years; these would all have to be kept in private branches,
>> causing all sorts of merging/rebasing headaches.
>> (d) It takes quite a lot of effort to maintain a large open source
>> project. It's not just dumping the source to Github.
>> 
>>> Yeah, the headers are visible, and Apple has
>>> info online. But sometimes that was not sufficient to understand the
>> actual
>>> implementation details.
>> 
>> You don't want to use the _implementation_ details! Those can and do
>> change completely over time — I know NSView has been
>> redesigned/reimplemented at least twice since 2000 — so making use of them
>> on OS version N could cause your app to break in version N+1. You want to
>> know the details of the (defined) _behaviors_. That means better
>> documentation. I agree that Apple could improve here.
>> 
>>> When debugging, the stack trace inside Cocoa was just a bunch of
>>> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes
>> 
>> That's not true; you can use symbolic breakpoints to break on any
>> Objective-C method, or any C function that has a visible symbol.
>> 
>>> I personally learned C++ while using the PowerPlant library from
>> Metrowerks.
>> 
>> The difference is that PP is code that you link statically into your app.
>> It doesn't change versions unless you explicitly update it. Cocoa is part
>> of the OS, and changes one very OS release. Binary compatibility is super
>> important to Apple, so Cocoa being a "black box" is actually a feature, not
>> a bug.
>> 
>> —Jens
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/aandi%40quite.com
>> 
>> This email sent to aa...@quite.com
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> 

Re: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 11 oct. 2019 à 16:59, Turtle Creek Software via Cocoa-dev 
>  a écrit :
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.


At least for ARC, it is fully open source.
The runtime part can be found in the objc4 project, and the compiler part come 
from clang, and is open source as well.

And knowing that, you will see that for such complex features, having them open 
source does not bring you many benefit to use them, as it is barely impossible 
to infer what the compiler optimiser pass will output by simply reading the 
source.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Charles Srstka via Cocoa-dev]

> On Oct 11, 2019, at 12:44 AM, Jens Alfke  wrote:
> 
> 
>> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>>  wrote:
>> 
>> Just a guess but perhaps management had an awakening when they found the 
>> time and effort expended to write the next even better version of Finder in 
>> Carbon was substantially more difficult and costly that the prior Cocoa 
>> version.
> 
> The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. 
> The development versions had a NeXT file manager with a Mac UI skin, but 
> before release that was replaced with a Carbon-ized port of (a subset of) the 
> MacOS 9 Finder. That Finder lived on for a few years before being replaced by 
> a new rewritten Cocoa version.
> 
> —Jens

The NeXT/Rhapsody file manager was what I was referring to.

As for the 10.0 Finder, I’m sure it shared code with the OS 9 finder, but it 
was an essentially new app based on PowerPlant (which the OS 9 Finder, to the 
best of my knowledge, was not). It did not feel much like the OS 9 Finder, and 
it was missing a lot of basic functionality that the OS 9 Finder had had, much 
of which was gradually reintroduced over the years. The Cocoa rewrite of the 
Finder did not appear until Snow Leopard was released in 2009. Notably, the 
Finder was still Carbon when Apple suddenly out of nowhere (again, from the 
perspective of an outsider) dropped the previously promised 64-bit Carbon 
support in 2007.

As for the Dock, there was no OS 9 analogue to that at all, so the only 
conclusion can be that it was rewritten in Carbon from the ground up, when a 
Cocoa one had been previously available. This is difficult to explain other 
than as a statement of confidence in Carbon.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 11:21 AM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> What you can do is give them feedback about your specific experience, as 
> you're doing, and I hope that someone at Apple is reading this thread and 
> taking notice.

When creating a new project in Xcode one of the choices is Cross-platform. 
Under this tab the only choice available is "Cross-platform Game".

A second choice "Cross-platform Cocoa App" would be great for the small 
developer who’s focus is on business applications. All whole world doesn’t 
revolve around games.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Turtle Creek Software via Cocoa-dev]

>> I know this is the Cocoa devs list... but why not make a website?
>> It would be easier to develop, completely crossplatform, no app store
complications, you would be in total control of your stack, etc.

QuickBooks has gone that route.  They still grudgingly sell desktop apps,
but really push people towards their cloud version.  Besides all the
benefits you mention, it's a steady monthly income.  Hence why Microsoft
and Adobe are also going that route.  Apple too.

But, we're a small company, and it would involve hosting other people's
vital data.  Risk of outages, security breaches, compliance and privacy
issues. It would require much more skill to maintain. In a way we are
gambling on a huge breach happening to Intuit some day. Then suddenly we
look really, really good.

Casey McDermott
TurtleSoft.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 6:18 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.

Totally reasonable. The ironic thing is that Cocoa is actually a lot easier to 
program in than Carbon (even with PowerPlant, I'd say.) But of course, any API 
you don't know is by definition harder to use than one you already know.

> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem.

Cocoa doesn't. I've never needed to disassemble framework code since I left 
Apple. There are probably some situations when dealing with weird bugs or 
misbehaviors where it would be useful to do so, but it's not typical.

> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring.

It's almost all Objective-C, actually. The C code is down in CoreFoundation. 
And that code gets refactored / rewritten as necessary, I'm sure — I know about 
major rewrites of NSView, NSTableView and NSTextView that occurred while I was 
still at Apple, and I'm sure there have been more since. It was very 
well-written code back then, and I'll bet it still is.

They've also done two complete redesigns — first UIKit, and now SwiftUI. You 
learn a lot when you rewrite something. SwiftUI in particular benefits from 
some big paradigm shifts (ugh) that have been happening in the field, like 
reactive programming.

> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. 

Not all this stuff is patentable, and patents are very expensive to file. Not 
having readily available source code to refer to raises the bar to entry.

I hope I won't offend you if I point out that as you are (as you freely admit) 
a small business that doesn't focus on CS or software engineering, you're not 
really in a position to give engineering or business advice to Apple. Apple has 
some of the best business and software people in the world, which is not to say 
that they don't make mistakes sometimes, but they generally have pretty good 
reasons for the way they do things. What you can do is give them feedback about 
your specific experience, as you're doing, and I hope that someone at Apple is 
reading this thread and taking notice.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Pier Bover via Cocoa-dev]

>
> Builders are mobile, and would love access to the accounting file in the
> office.   Those apps will each do just one thing (e.g. enter a purchase or
> check an estimate).


I know this is the Cocoa devs list... but why not make a website?

It would be easier to develop, completely crossplatform, no app store
complications, you would be in total control of your stack, etc.

On Fri, Oct 11, 2019 at 12:10 PM Turtle Creek Software via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> After we finish the Windows update, the plan is to write small phone/pad
> apps that will talk to it.  Builders are mobile, and would love access to
> the accounting file in the office.   Those apps will each do just one thing
> (e.g. enter a purchase or check an estimate). Swift and the current Cocoa
> will work great for those.  No need for any C++.  One screen or maybe a
> couple.  Not much interface. I don't know quite what the network technology
> will be yet, but phone-to-desktop will have advantages over pure
> cloud-based apps.  Cocoa and iOS seem strong at passing data over the
> Internet.  We'll do iOS first, then subcontract matching Android apps
> later.
>
> Desktop business apps are more complicated, and that's where Cocoa failed
> for us.  Cocoa probably is difficult for any code base that does something
> complex, and wants to be cross-platform for the model layer.  It would be
> insane for us to write payroll code in two different languages.  Not just
> the programmer time, it's also a lot of extra testing and debugging. Twice
> the maintenance, forever.
>
> At the beginning we assumed that the hard part would be learning
> Objective-C, and finding a way to link C++ to it.  Those were surprisingly
> easy.  Basic architecture also was easy.  Powerplant was pretty much just
> V, but we evolved into MVC very early on. There already are RecordViewer
> classes that act very much like a NSViewController, so we just link them.
>
> After 3 or 4 months the app was already starting to look and work like the
> current version. Then we discovered NSOutlineView and MFC's CTreeView, and
> designed a single-window setup that was much better than our current
> many-windows approach.  At that point we were extremely optimistic.
>
> Then began the long slog to get everything to actually work right.
> NSComboBox was almost perfect, but we needed it to only allow existing
> items. Apple docs said it was possible but we never got it to work, even
> with suggestions from this list. So it required a text field, popup and
> table view, with complex interactions between them.  Meanwhile CComboBox in
> MFC did it right with just a single parameter.  Our data entry tables have
> complicated interactions between cells. Trying to get them to work in a
> NSTableView burned up almost a year.  We finally gave up and changed the
> interface entirely.  Constraints were a constant hassle.  Looking ahead to
> how much detail still needs a rewrite was the last straw.  There are still
> about 40 windows currently made in MW Constructor that will each need a nib
> and controller.  At one week apiece for those, the horizon receded too far.
>
> Casey McDermott
> TurtleSoft.com
>
> On Fri, Oct 11, 2019 at 11:35 AM Gary L. Wade <
> garyw...@desisoftsystems.com>
> wrote:
>
> > Clarification: For long-time Mac and now available in SwiftUI, you can
> > even write “no” code to do some things with bindings.
> > --
> > Gary L. Wade
> > http://www.garywade.com/
> >
> > > On Oct 11, 2019, at 8:31 AM, Gary L. Wade <
> garyw...@desisoftsystems.com>
> > wrote:
> > >
> > > For Mac and SwiftUI, you can even write “no” code to do some things
> with
> > bindings.
> >
> >
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/pierbover11%40gmail.com
>
> This email sent to pierbove...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Turtle Creek Software via Cocoa-dev]

After we finish the Windows update, the plan is to write small phone/pad
apps that will talk to it.  Builders are mobile, and would love access to
the accounting file in the office.   Those apps will each do just one thing
(e.g. enter a purchase or check an estimate). Swift and the current Cocoa
will work great for those.  No need for any C++.  One screen or maybe a
couple.  Not much interface. I don't know quite what the network technology
will be yet, but phone-to-desktop will have advantages over pure
cloud-based apps.  Cocoa and iOS seem strong at passing data over the
Internet.  We'll do iOS first, then subcontract matching Android apps later.

Desktop business apps are more complicated, and that's where Cocoa failed
for us.  Cocoa probably is difficult for any code base that does something
complex, and wants to be cross-platform for the model layer.  It would be
insane for us to write payroll code in two different languages.  Not just
the programmer time, it's also a lot of extra testing and debugging. Twice
the maintenance, forever.

At the beginning we assumed that the hard part would be learning
Objective-C, and finding a way to link C++ to it.  Those were surprisingly
easy.  Basic architecture also was easy.  Powerplant was pretty much just
V, but we evolved into MVC very early on. There already are RecordViewer
classes that act very much like a NSViewController, so we just link them.

After 3 or 4 months the app was already starting to look and work like the
current version. Then we discovered NSOutlineView and MFC's CTreeView, and
designed a single-window setup that was much better than our current
many-windows approach.  At that point we were extremely optimistic.

Then began the long slog to get everything to actually work right.
NSComboBox was almost perfect, but we needed it to only allow existing
items. Apple docs said it was possible but we never got it to work, even
with suggestions from this list. So it required a text field, popup and
table view, with complex interactions between them.  Meanwhile CComboBox in
MFC did it right with just a single parameter.  Our data entry tables have
complicated interactions between cells. Trying to get them to work in a
NSTableView burned up almost a year.  We finally gave up and changed the
interface entirely.  Constraints were a constant hassle.  Looking ahead to
how much detail still needs a rewrite was the last straw.  There are still
about 40 windows currently made in MW Constructor that will each need a nib
and controller.  At one week apiece for those, the horizon receded too far.

Casey McDermott
TurtleSoft.com

On Fri, Oct 11, 2019 at 11:35 AM Gary L. Wade 
wrote:

> Clarification: For long-time Mac and now available in SwiftUI, you can
> even write “no” code to do some things with bindings.
> --
> Gary L. Wade
> http://www.garywade.com/
>
> > On Oct 11, 2019, at 8:31 AM, Gary L. Wade 
> wrote:
> >
> > For Mac and SwiftUI, you can even write “no” code to do some things with
> bindings.
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Gary L. Wade via Cocoa-dev]

Clarification: For long-time Mac and now available in SwiftUI, you can even 
write “no” code to do some things with bindings.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:31 AM, Gary L. Wade  
> wrote:
> 
> For Mac and SwiftUI, you can even write “no” code to do some things with 
> bindings.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Gary L. Wade via Cocoa-dev]

I’m one of the few on the list who has experienced every growing pain you’ve 
mentioned from 680x0 Macintosh now up to SwiftUI, and not only supporting a US 
English environment but even RTL UI (Arabic and Hebrew scripts) mixed with LTR 
languages across every current platform, and I will admit it’s hard.

The way I found Cocoa development to be easier was to change my way of 
thinking. In almost every case, it was better to completely separate the 
business logic from the UI handling logic. In other frameworks, the paradigm is 
to subclass a view; in Cocoa, everything is built to be as MVC as possible. Of 
course, there are exceptions, but if you find yourself wanting to subclass a 
view, think hard and look around—it might be better to compose a view of other 
views or there is a better, more Cocoa way of doing it. For Mac and SwiftUI, 
you can even write “no” code to do some things with bindings.

It’s possible to do a progressive port, but in many cases, you might find it 
easier to re-model (pun intended) your design.

True, the classes you mentioned are difficult, but I’ve seen many of their 
difficulties in thinking of them as a 1-1 replacement for comparable 
affordances in other frameworks or platforms.

Definitely use your tech support incidents, and if you find something not 
behaving as defined or not defined well, submit feedback to Apple and feel free 
to post those here. There’s also a site where you can voluntarily add your 
feedback requests to Apple, but I don’t recall it right now.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:00 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.
> 
> In general, we weren't curious at all about the inner implementations of
> Cocoa.  The problems that held us back were in getting it to work for our
> app. Something is drawing solid black.  Why?
> 
> Rather than crown jewels, I think the best analogy for Cocoa should be an
> excavator or a backhoe. Some people run one full-time, but some pick it up
> from the rental place, and just want to get some stuff done over a
> weekend.  What's the best way to make it productive, quickly?  The
> long-time operators on this list know all the tricks, but Cocoa should also
> allow the rest of us to build apps relatively quickly. In our case, that
> means less than 3 years.
> 
> Casey McDermott
> TurtleSoft.com
> 
>> On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha  wrote:
>> 
>> I’m sure much of the Cocoa code is quite old, but it’s mostly all
>> Objective-C. If you’re curious how it might work, but don’t want to use a
>> disassembler, the GNUstep project has a somewhat decent (though
>> incomplete) reimplementation  that
>> you can look at.
>> 
>> Saagar Jha
>> 
>> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>> 
>> If you combine otool, classdump and Hopper Disassembler, you can find
>> 
>> how some Cocoa methods are working in any Obj-C executable pretty easily.
>> 
>> Here's the thing.  We started out as construction folks who learned Excel.
>> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
>> construction business, and how to talk to folks in it. Our time is best
>> spent solving business-related problems.  Along the way we have learned
>> many programming and human-interface skills, but the less time we need to
>> spend on that, the better.
>> 
>> If a programming environment requires zombies, disassemblers and other BS
>> just to make it work, that is a big problem. It's too much extra overhead.
>> Our company can't afford it.
>> 
>> I'd agree that the documentation for Cocoa is deficient.
>> 
>> CodeWarrior included a huge Inside PowerPlant book, modeled on our
>> well-worn copies of Inside Macintosh. But we rarely used it.  Having
>> clearly-written source code and good comments is probably the best form of
>> documentation. Being able to step through it easily and see it in action is
>> a huge plus.
>> 
>> I suspect that Cocoa source code is ancient C that is badly in need of a
>> refactoring. Making it open, understandable and self-documenting would be a
>> great way to improve it.  Based on our refactoring experiences, it would
>> end up being faster, safer and less buggy.
>> 
>> There probably are some parts of Cocoa that are extremely proprietary- but
>> even then, plain old patents are better than hiding the code, as a way to
>> protect the jewels. Competitors can always disassemble, as you suggest.
>> 
>> Speaking of 

Re: Thoughts on Cocoa source code

[Turtle Creek Software via Cocoa-dev]

I checked the GNUstep project, and it does seem decently clear and
well-commented. If Apple made it possible to see and step through some of
the basic Cocoa classes, that would be a good starting point.  The hard
parts for us were NSView and its subclasses (especially NSTableView &
associates, NSTabView and NSComboBox in that order).  The whole constraint
system.  ARC.  Getting nibs to work properly when one little setting was
wrong.

In general, we weren't curious at all about the inner implementations of
Cocoa.  The problems that held us back were in getting it to work for our
app. Something is drawing solid black.  Why?

Rather than crown jewels, I think the best analogy for Cocoa should be an
excavator or a backhoe. Some people run one full-time, but some pick it up
from the rental place, and just want to get some stuff done over a
weekend.  What's the best way to make it productive, quickly?  The
long-time operators on this list know all the tricks, but Cocoa should also
allow the rest of us to build apps relatively quickly. In our case, that
means less than 3 years.

Casey McDermott
TurtleSoft.com

On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha  wrote:

> I’m sure much of the Cocoa code is quite old, but it’s mostly all
> Objective-C. If you’re curious how it might work, but don’t want to use a
> disassembler, the GNUstep project has a somewhat decent (though
> incomplete) reimplementation  that
> you can look at.
>
> Saagar Jha
>
> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> If you combine otool, classdump and Hopper Disassembler, you can find
>
> how some Cocoa methods are working in any Obj-C executable pretty easily.
>
> Here's the thing.  We started out as construction folks who learned Excel.
> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
> construction business, and how to talk to folks in it. Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.
>
> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem. It's too much extra overhead.
> Our company can't afford it.
>
> I'd agree that the documentation for Cocoa is deficient.
>
> CodeWarrior included a huge Inside PowerPlant book, modeled on our
> well-worn copies of Inside Macintosh. But we rarely used it.  Having
> clearly-written source code and good comments is probably the best form of
> documentation. Being able to step through it easily and see it in action is
> a huge plus.
>
> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring. Making it open, understandable and self-documenting would be a
> great way to improve it.  Based on our refactoring experiences, it would
> end up being faster, safer and less buggy.
>
> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. Competitors can always disassemble, as you suggest.
>
> Speaking of early-Aughties history. We hired some subs to write the Windows
> version of our app. They took a short-cut and used QuickTime DLLs, though a
> lot still needed native MFC.  Metrowerks offered to buy it from us so they
> could make PowerPlant cross-platform.  Sadly, before we finished
> negotiations, Motorola did a re-org and our contact disappeared.  MW soon
> sold off their Intel compiler, just in time for Mac to switch chips. The
> rest is history.
>
> Casey McDermott
> TurtleSoft.com
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
>
> This email sent to saa...@saagarjha.com
>
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Saagar Jha via Cocoa-dev]

I’m sure much of the Cocoa code is quite old, but it’s mostly all Objective-C. 
If you’re curious how it might work, but don’t want to use a disassembler, the 
GNUstep project has a somewhat decent (though incomplete) reimplementation 
 that you can look at.

Saagar Jha

> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
>>> If you combine otool, classdump and Hopper Disassembler, you can find
> how some Cocoa methods are working in any Obj-C executable pretty easily.
> 
> Here's the thing.  We started out as construction folks who learned Excel.
> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
> construction business, and how to talk to folks in it. Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.
> 
> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem. It's too much extra overhead.
> Our company can't afford it.
> 
> I'd agree that the documentation for Cocoa is deficient.
> 
> CodeWarrior included a huge Inside PowerPlant book, modeled on our
> well-worn copies of Inside Macintosh. But we rarely used it.  Having
> clearly-written source code and good comments is probably the best form of
> documentation. Being able to step through it easily and see it in action is
> a huge plus.
> 
> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring. Making it open, understandable and self-documenting would be a
> great way to improve it.  Based on our refactoring experiences, it would
> end up being faster, safer and less buggy.
> 
> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. Competitors can always disassemble, as you suggest.
> 
> Speaking of early-Aughties history. We hired some subs to write the Windows
> version of our app. They took a short-cut and used QuickTime DLLs, though a
> lot still needed native MFC.  Metrowerks offered to buy it from us so they
> could make PowerPlant cross-platform.  Sadly, before we finished
> negotiations, Motorola did a re-org and our contact disappeared.  MW soon
> sold off their Intel compiler, just in time for Mac to switch chips. The
> rest is history.
> 
> Casey McDermott
> TurtleSoft.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Turtle Creek Software via Cocoa-dev]

>> If you combine otool, classdump and Hopper Disassembler, you can find
how some Cocoa methods are working in any Obj-C executable pretty easily.

Here's the thing.  We started out as construction folks who learned Excel.
Then HyperTalk.  Then C++. As a business, our main strength is knowing the
construction business, and how to talk to folks in it. Our time is best
spent solving business-related problems.  Along the way we have learned
many programming and human-interface skills, but the less time we need to
spend on that, the better.

If a programming environment requires zombies, disassemblers and other BS
just to make it work, that is a big problem. It's too much extra overhead.
Our company can't afford it.

I'd agree that the documentation for Cocoa is deficient.

CodeWarrior included a huge Inside PowerPlant book, modeled on our
well-worn copies of Inside Macintosh. But we rarely used it.  Having
clearly-written source code and good comments is probably the best form of
documentation. Being able to step through it easily and see it in action is
a huge plus.

I suspect that Cocoa source code is ancient C that is badly in need of a
refactoring. Making it open, understandable and self-documenting would be a
great way to improve it.  Based on our refactoring experiences, it would
end up being faster, safer and less buggy.

There probably are some parts of Cocoa that are extremely proprietary- but
even then, plain old patents are better than hiding the code, as a way to
protect the jewels. Competitors can always disassemble, as you suggest.

Speaking of early-Aughties history. We hired some subs to write the Windows
version of our app. They took a short-cut and used QuickTime DLLs, though a
lot still needed native MFC.  Metrowerks offered to buy it from us so they
could make PowerPlant cross-platform.  Sadly, before we finished
negotiations, Motorola did a re-org and our contact disappeared.  MW soon
sold off their Intel compiler, just in time for Mac to switch chips. The
rest is history.

Casey McDermott
TurtleSoft.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> Just a guess but perhaps management had an awakening when they found the time 
> and effort expended to write the next even better version of Finder in Carbon 
> was substantially more difficult and costly that the prior Cocoa version.

The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. The 
development versions had a NeXT file manager with a Mac UI skin, but before 
release that was replaced with a Carbon-ized port of (a subset of) the MacOS 9 
Finder. That Finder lived on for a few years before being replaced by a new 
rewritten Cocoa version.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Richard Charles via Cocoa-dev]

> On Oct 10, 2019, at 5:20 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
> Yes, they marketed Carbon as a first-class citizen, promoted as “the basis 
> for all life,” and even rewrote the Finder and Dock—which already had Cocoa 
> implementations from NeXT—in Carbon just to prove that they were serious 
> about it.

Just a guess but perhaps management had an awakening when they found the time 
and effort expended to write the next even better version of Finder in Carbon 
was substantially more difficult and costly that the prior Cocoa version.

> I still remember reading this thread, and feeling nervous about it:
> 
> https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01366.html

Yes this is a very interesting thread. Here is a post on the same thread 
written by Erik M. Buck.

https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01329.html

"Carbon will exist as long as Apple exists.”

Apparently this is the same Erik M. Buck who coauthored the excellent book 
Cocoa Design Patterns with Donald Yacktman which came out in 2009.

So apparently Mr. Buck saw the light and had a change of mind. Apparently a lot 
of individuals at Apple had a change of mind and saw the light as Cocoa 
demonstrated itself superior technology. I think that is what happened.

> The common assumption among the more level-headed at the time was that Cocoa 
> was going to be gradually rewritten to sit on top of Carbon, with Carbon 
> sticking around as the lower-level, closer-to-the-metal API.

My guess is maybe outside the company this may have been the common view but 
not to every one inside the company. Core Foundation made Carbon possible on 
the new OS. It was written by borrowing stuff from Cocoa not the other way 
around.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Charles Srstka via Cocoa-dev]

> On Oct 4, 2019, at 4:51 AM, Jeremy Hughes via Cocoa-dev 
>  wrote:
> 
> Hi Jens,
> 
>> On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > > wrote:
>> 
>> The people I hear complaining about this are those who, like you, didn't 
>> move to Cocoa. Carbon was a _temporary_ transition API*. 
> 
> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 
> 2007, when Apple suddenly abandoned 64-bit Carbon.

Yes, they marketed Carbon as a first-class citizen, promoted as “the basis for 
all life,” and even rewrote the Finder and Dock—which already had Cocoa 
implementations from NeXT—in Carbon just to prove that they were serious about 
it.

That last detail made a lot of people nervous about *Cocoa’s* future. There was 
a real possibility that it could have gone the way of OpenDoc or GX and joined 
the large graveyard of supposedly superior Apple technologies, whereas Carbon 
was the only framework being used by all the big clients that Apple couldn’t 
survive without, and for those first few years, it seemed to get a lot more 
development attention (Cocoa didn’t even support proper drag and drop until 
Jaguar).

I still remember reading this thread, and feeling nervous about it:

https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01366.html

The common assumption among the more level-headed at the time was that Cocoa 
was going to be gradually rewritten to sit on top of Carbon, with Carbon 
sticking around as the lower-level, closer-to-the-metal API. They actually did 
partially do this—for example, I think that the menu system is still Carbon 
under the hood.

In retrospect, it seems clear that the real issue driving things was that Apple 
in 2001 did not have the clout that they had in 2007. Apple was in a rather 
precarious position at the time, and was in no position to dictate terms to its 
large vendors like Adobe and Microsoft on whom it depended for its survival. If 
we had known the success that Apple would subsequently reach, we might have 
been able to predict that Carbon would eventually be phased out, but to those 
living in the moment, there was no guarantee that that would happen, or even 
that Apple would still be around after all this time (indeed, if the 
inevitability of this *had* been obvious, I would have loaded up on stock). 
Hindsight is easy.

None of that makes it surprising that Carbon is gone in 2019, though (sadly, as 
I’m going to miss a lot of the game library that’s being wiped out by this).

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Stephane Sudre via Cocoa-dev]

On Wed, Oct 9, 2019 at 7:19 PM Turtle Creek Software via Cocoa-dev
 wrote:
>
> Why is Cocoa source code hidden?
>
> Many of the frustrations we had with the 64-bit update attempt were caused
> by Cocoa's lack of visible source. It was a "black box" that often required
> trial-and-error to figure out. Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.

Cocoa source code is not really hidden if you use the proper tools and
know how to use them and that you should not rely 100% on them.

With Hopper Disassembler, you can see any Obj-C framework source code
in /System/Library/(Private)Frameworks.

Although most of the time you don't need to see the source code, there
are some areas that are poorly covered by the developer documentation
and being able to see the implementation details is very useful. For
instance, if you ever had to write a custom subclass of NSCell or a
subclass of NSControl with multiple cells, the official documentation
was almost totally useless and this was a good opportunity to find out
about the private API Apple was keeping to itself to make the AppKit
controls work.

It's true that having access to the source code can also help finding
issues and suggesting patches. But it's also true that if Apple had
been doing a proper job at checking the warnings and static analysis
outputs of its own IDE, numerous issues could have been fixed without
having needed to be reported by 3rd party developers.

If you combine otool, classdump and Hopper Disassembler, you can find
how some Cocoa methods are working in any Obj-C executable pretty
easily.

https://www.hopperapp.com

http://stevenygard.com/projects/class-dump/

Checking cocotron can also be helpful if you want to see how someone
else implemented most Foundation and AppKit legacy APIs.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 10 oct. 2019 à 00:14, Jens Alfke via Cocoa-dev  
> a écrit :
> 
> 
> 
>> On Oct 9, 2019, at 11:39 AM, Aandi Inston  wrote:
>> 
>> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get 
>> a compile-time warning.
> 
> Only if you don't turn on -Werror, which I really, really recommend everyone 
> do. Calling a method that a class isn't declared as implementing is a fairly 
> common mistake, and warnings are way too easy to overlook.
> 
> In this situation, you get around the warning/error by declaring the method 
> yourself in a category on the framework class.
> 
>> * I add a check for actual OS version, so I am very sure not try to call  
>> [NSApplication doUsefulThing] 
>> unless the OS is 10.15 or later.
>> * But what happens if it runs in 10.15? Does it actually do the useful thing?
> 
> The method will be called, yes. I can't think of any particular reason it 
> wouldn't work. 

It may not work if -doUsefulThing rely on some code that performs a « Link SDK 
version » runtime check and assume the new code path wlll be executed because 
this method is not supposed to be called from a app linked on an older SDK..

This is rather unlikely, but this is usually safer to update your SDK if you 
want the last features.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 9, 2019, at 11:39 AM, Aandi Inston  wrote:
> 
> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get a 
> compile-time warning.

Only if you don't turn on -Werror, which I really, really recommend everyone 
do. Calling a method that a class isn't declared as implementing is a fairly 
common mistake, and warnings are way too easy to overlook.

In this situation, you get around the warning/error by declaring the method 
yourself in a category on the framework class.

> * I add a check for actual OS version, so I am very sure not try to call  
> [NSApplication doUsefulThing] 
> unless the OS is 10.15 or later.
> * But what happens if it runs in 10.15? Does it actually do the useful thing?

The method will be called, yes. I can't think of any particular reason it 
wouldn't work. 

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Saagar Jha via Cocoa-dev]

Nothing is statically linked. The version of the SDK you compile with is 
embedded into your application and Cocoa (and other Apple frameworks) consult 
this at runtime to determine appropriate behavior. Often this means you don’t 
get the new behavior, but sometimes Apple will automatically “opt you in” if 
they feel like it doesn’t break too many applications (for example, macOS 
Sierra’s window tabbing).

Saagar Jha

[Snipped to stay under the list limit]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Alan Snyder via Cocoa-dev]

> On Oct 9, 2019, at 10:41 AM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> You don't want to use the _implementation_ details! Those can and do change 
> completely over time

There is a situation where I think it is fine to use the implementation 
details, and that is to work around a problem in an old release of macOS, which 
is never going to be changed (with the possible exception of a security patch, 
I suppose, but that is unlikely to cause any problems).

Believe it or not, some bugs are not fixed until the next release, or the one 
after that, or …


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 9, 2019, at 11:58 AM, Pier Bover  wrote:
> 
> For example Imagix is a company that does image transformation in the cloud 
> and uses macs because of the high performance of CoreImage 
> (https://photos.imgix.com/racking-mac-pros) It's still more cost effective 
> for them to use expensive macs vs linux servers because of the performance 
> increase. Pretty amazing if you think about it.

They should be thrilled that Apple announced an optimized version of the 2019 
Mac Pro for rack deployment.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Aandi Inston via Cocoa-dev]

" . Cocoa is part of the OS, and changes one very OS release. "

This reminds me of a question which pops up for me every few years in
development. I can't call to mind the last
specific details, but it will happen again.
Let's create an imaginary problem:
* Apple add a new class behaviour to Cocoa in macOS 10.15. We'll suppose
they add [NSApplication doUsefulThing]
* But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get
a compile-time warning. Still, I'd
really like to do the useful thing anyway, and without changing the SDK for
whatever reason.
* I add a check for actual OS version, so I am very sure not try to call
[NSApplication doUsefulThing]
unless the OS is 10.15 or later.
* But what happens if it runs in 10.15? Does it actually do the useful
thing?
Are the Cocoa methods entirely dynamically loaded/provided by the live OS?
Or does anything get statically linked,
flagged, is the binary's SDK version checked or is there anything else that
will prevent this call doing the
useful thing?

Thanks in advance!

On Wed, 9 Oct 2019 at 18:42, Jens Alfke via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

>
>
> > On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> > Why is Cocoa source code hidden?
>
> So, take this as opinions of someone who worked at Apple, on [among other
> things] Mac OS X apps from 2000-2007.
>
> (a) It's part of Apple's crown jewels and seen as a competitive advantage.
> (b) It calls all sorts of internal APIs of lower-level components like the
> WindowServer, and Apple doesn't want to expose those APIs because they're
> undocumented, easily misused, hard to support, subject to change at any
> moment, etc.
> (c) If developers look at the source code they'll be tempted to make use
> of undocumented behaviors, private methods, etc. which makes their apps
> much more likely to break in future OS versions. (This already does happen,
> to an extent, but with source code it would be much more pervasive, given
> the dynamic nature of Obj-C and how easy it is to call internal methods or
> even patch system classes.)
> (d) Internal source code tends to have comments and identifiers that refer
> to internal code names, canceled projects, and other stuff that shouldn't
> be made public. Sanitizing this is a pain.
> (e) Apple obviously works on lots of features that remain secret for
> months or years; these would all have to be kept in private branches,
> causing all sorts of merging/rebasing headaches.
> (d) It takes quite a lot of effort to maintain a large open source
> project. It's not just dumping the source to Github.
>
> > Yeah, the headers are visible, and Apple has
> > info online. But sometimes that was not sufficient to understand the
> actual
> > implementation details.
>
> You don't want to use the _implementation_ details! Those can and do
> change completely over time — I know NSView has been
> redesigned/reimplemented at least twice since 2000 — so making use of them
> on OS version N could cause your app to break in version N+1. You want to
> know the details of the (defined) _behaviors_. That means better
> documentation. I agree that Apple could improve here.
>
> > When debugging, the stack trace inside Cocoa was just a bunch of
> > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes
>
> That's not true; you can use symbolic breakpoints to break on any
> Objective-C method, or any C function that has a visible symbol.
>
> > I personally learned C++ while using the PowerPlant library from
> Metrowerks.
>
> The difference is that PP is code that you link statically into your app.
> It doesn't change versions unless you explicitly update it. Cocoa is part
> of the OS, and changes one very OS release. Binary compatibility is super
> important to Apple, so Cocoa being a "black box" is actually a feature, not
> a bug.
>
> —Jens
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aandi%40quite.com
>
> This email sent to aa...@quite.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Pier Bover via Cocoa-dev]

> Perhaps Apple does not want to give away the Crown Jewels.

Indeed.

There is some stuff in there that AFAIK no one has been able to replicate.

For example Imagix is a company that does image transformation in the cloud
and uses macs because of the high performance of CoreImage (
https://photos.imgix.com/racking-mac-pros) It's still more cost effective
for them to use expensive macs vs linux servers because of the performance
increase. Pretty amazing if you think about it.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Richard Charles via Cocoa-dev]

> On Oct 9, 2019, at 11:19 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Why is Cocoa source code hidden?

Because Apple does not want to expose Cocoa source source. It is proprietary 
software.

> Many of the frustrations we had with the 64-bit update attempt were caused
> by Cocoa's lack of visible source. It was a "black box" that often required
> trial-and-error to figure out. Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.
> 
> When debugging, the stack trace inside Cocoa was just a bunch of
> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or
> step through their C code. More mysteries and headaches.

I agree reading assembly is horrid. Did you know that you can set a symbolic 
breakpoint on code inside the Cocoa frameworks? You can also swizzle a 
framework method to gain insight into what Apple is doing. You can also examine 
Cocotron source code for insight into what maybe going on behind the scenes.

> I personally learned C++ while using the PowerPlant library from
> Metrowerks. Its source files were totally exposed. Seeing comments and code
> really helped. When designing or debugging, it was possible to step through
> their code and see exactly how it functioned.  Cocoa would be so much
> easier to use if its source was accessible like that.
> 
> In fact, why isn't Cocoa open source?  Apple open-sources Swift and the
> Darwin kernel. Surely the GUI can't be any riskier to expose to developers?

Perhaps Apple does not want to give away the Crown Jewels.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Saagar Jha via Cocoa-dev]

Saagar Jha

> On Oct 9, 2019, at 10:19, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Why is Cocoa source code hidden?
> 
> Many of the frustrations we had with the 64-bit update attempt were caused
> by Cocoa's lack of visible source. It was a "black box" that often required
> trial-and-error to figure out. Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.
> 
> When debugging, the stack trace inside Cocoa was just a bunch of
> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or
> step through their C code. More mysteries and headaches.

You can set symbolic breakpoints inside of Cocoa. And a good disassembler will 
get you a significant portion of the way there if you’re trying to debug in the 
internals of a method.

> I personally learned C++ while using the PowerPlant library from
> Metrowerks. Its source files were totally exposed. Seeing comments and code
> really helped. When designing or debugging, it was possible to step through
> their code and see exactly how it functioned.  Cocoa would be so much
> easier to use if its source was accessible like that.
> 
> In fact, why isn't Cocoa open source?  Apple open-sources Swift and the
> Darwin kernel. Surely the GUI can't be any riskier to expose to developers?
> 
> Our programmers found several PowerPlant bugs over the years. We fixed them
> right away in our copy, and reported them so they were fixed in the next
> update. Apple could get the same benefit for Cocoa. Seems like a win-win.
> 
> Someone suggested that I send comments to Tim Cook or whomever at Apple.
> That seems a good idea, but I'd like to see discussion results, first.
> Assemble more viewpoints.
> 
> Casey McDermott
> TurtleSoft.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Why is Cocoa source code hidden?

So, take this as opinions of someone who worked at Apple, on [among other 
things] Mac OS X apps from 2000-2007.

(a) It's part of Apple's crown jewels and seen as a competitive advantage.
(b) It calls all sorts of internal APIs of lower-level components like the 
WindowServer, and Apple doesn't want to expose those APIs because they're 
undocumented, easily misused, hard to support, subject to change at any moment, 
etc.
(c) If developers look at the source code they'll be tempted to make use of 
undocumented behaviors, private methods, etc. which makes their apps much more 
likely to break in future OS versions. (This already does happen, to an extent, 
but with source code it would be much more pervasive, given the dynamic nature 
of Obj-C and how easy it is to call internal methods or even patch system 
classes.)
(d) Internal source code tends to have comments and identifiers that refer to 
internal code names, canceled projects, and other stuff that shouldn't be made 
public. Sanitizing this is a pain.
(e) Apple obviously works on lots of features that remain secret for months or 
years; these would all have to be kept in private branches, causing all sorts 
of merging/rebasing headaches.
(d) It takes quite a lot of effort to maintain a large open source project. 
It's not just dumping the source to Github.

> Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.

You don't want to use the _implementation_ details! Those can and do change 
completely over time — I know NSView has been redesigned/reimplemented at least 
twice since 2000 — so making use of them on OS version N could cause your app 
to break in version N+1. You want to know the details of the (defined) 
_behaviors_. That means better documentation. I agree that Apple could improve 
here.

> When debugging, the stack trace inside Cocoa was just a bunch of
> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes

That's not true; you can use symbolic breakpoints to break on any Objective-C 
method, or any C function that has a visible symbol.

> I personally learned C++ while using the PowerPlant library from Metrowerks. 

The difference is that PP is code that you link statically into your app. It 
doesn't change versions unless you explicitly update it. Cocoa is part of the 
OS, and changes one very OS release. Binary compatibility is super important to 
Apple, so Cocoa being a "black box" is actually a feature, not a bug.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa source code

[Ben Kennedy via Cocoa-dev]

> On 09 Oct 2019, at 1:19 pm, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> In fact, why isn't Cocoa open source?  Apple open-sources Swift and the
> Darwin kernel. Surely the GUI can't be any riskier to expose to developers?

This is a business strategy question, not a Cocoa development question. 
Besides, nobody on this list will have an authoritative or succinct answer.

-ben

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 5 oct. 2019 à 07:14, Pier Bover via Cocoa-dev  
> a écrit :
> 
>> But once you get experienced with Cocoa and Objective-C, you can build
> applications or rewrite them fairly quickly, IMHO.
> Yeah but Objective-C is slowly being phased out. Someone from Apple already
> said in a previous e-mail newer APIs are only available for Swift.
> 
> As for Cocoa it seems like it will be slowly replaced by the iOS SDK or by
> newer APIs that are universal. Who knows, Apple doesn't usually do a great
> about communicating its medium term plans. Maybe in 5 years Cocoa or
> Objective-C will be phased out much like Carbon.

AppKit is not Cocoa. iOS SDK shared most fo its code with the macOS SDK, so 
even if it had to replace it (which is absolute non-sense seeing where Apple is 
going with Swift UI), it would be a far less big deal than the Carbon/Cocoa 
transition.

And Obj-C is not going to be more deprecated than C++ was deprecated with 
Carbon. A language is not a framework.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Pier Bover via Cocoa-dev]

> But once you get experienced with Cocoa and Objective-C, you can build
applications or rewrite them fairly quickly, IMHO.
Yeah but Objective-C is slowly being phased out. Someone from Apple already
said in a previous e-mail newer APIs are only available for Swift.

As for Cocoa it seems like it will be slowly replaced by the iOS SDK or by
newer APIs that are universal. Who knows, Apple doesn't usually do a great
about communicating its medium term plans. Maybe in 5 years Cocoa or
Objective-C will be phased out much like Carbon.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Laurent Daudelin via Cocoa-dev]

> 
> On Oct 4, 2019, at 23:43, Michael Hall via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Oct 4, 2019, at 2:41 PM, Lars C. Hassing via Cocoa-dev 
>>  wrote:
>> 
>> 
>> On 4 Oct 2019, at 21.00, Jens Alfke wrote:
>> 
>> The people I hear complaining about this are those who, like you, didn't 
>> move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary 
>> when Mac OS X shipped in March 2001, but even though it wasn't yet formally 
>> deprecated, it was clear it would be.
>> 
>> Carbon might have started as a temporary solution, but it ended up a very 
>> good solution,
>> which Apple stated in "It’s the Future” (Last updated: 2004-06-28)
>> 
>>  "Apple is committed to the HIViews, Carbon events, and nib files for Carbon 
>> implementations of the user interface.
>>   All new controls and other features will be based on HIView.
>>   If you want your application to take advantage of the latest features, you 
>> need to adopt the modern HIToolbox.”
>> 
>> https://web.archive.org/web/20080725021421/http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/upgrading_hitoolbox_conc/chapter_2_section_7.html
>> 
>> 
>> When my company was going to the Mac platform (in addition to 
>> Sun+AIX+Windows),
>> Carbon seemed like a good choice.
>> Now we have just wasted several man years going to Cocoa.
>> Microsoft is really the good guys, as somebody said, not letting developers 
>> down.
>> /Lars
> 
> Does anyone remember when Cocoa / Carbon / Java were all supposed to be valid 
> paths forward on OS X?
> 
> A quick search turned up...
> http://ec30.org/skills/mac-os-x-carbon-cocoa-development/ 
> 
> 
> Notice the application frameworks in the image at the front.
> 
> It wasn’t always clear that Cocoa was going to be the last man standing on OS 
> X.
> 

Anybody who would have done a little bit of research about the origin of OS X 
would have found it was originally NeXTSTEP, then OPENSTEP, which had an 
Objective-C base and where every application was built using Cocoa. Of course, 
at some point, the older technologies were bound to be deprecated. I’m also 
sorry for the small developers who have to go through those changes. I’m a lone 
developer myself and I know how it can be hard sometimes. We have powerful 
tools to write applications these days. Compared to the THINK Class Library and 
Metrowerks, the tools that were available to build Cocoa apps back then (and 
even these days) were lightyears ahead of these primitive tools. Of course, 
there was the learning curve for people coming from Carbon and C++. But once 
you get experienced with Cocoa and Objective-C, you can build applications or 
rewrite them fairly quickly, IMHO. 

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
Logiciels Némésys Software  
http://www.nemesys-soft.com/ 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Michael Hall via Cocoa-dev]

> On Oct 4, 2019, at 2:41 PM, Lars C. Hassing via Cocoa-dev 
>  wrote:
> 
> 
> On 4 Oct 2019, at 21.00, Jens Alfke wrote:
> 
> The people I hear complaining about this are those who, like you, didn't move 
> to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac 
> OS X shipped in March 2001, but even though it wasn't yet formally 
> deprecated, it was clear it would be.
> 
> Carbon might have started as a temporary solution, but it ended up a very 
> good solution,
> which Apple stated in "It’s the Future” (Last updated: 2004-06-28)
> 
>   "Apple is committed to the HIViews, Carbon events, and nib files for Carbon 
> implementations of the user interface.
>All new controls and other features will be based on HIView.
>If you want your application to take advantage of the latest features, you 
> need to adopt the modern HIToolbox.”
> 
> https://web.archive.org/web/20080725021421/http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/upgrading_hitoolbox_conc/chapter_2_section_7.html
> 
> 
> When my company was going to the Mac platform (in addition to 
> Sun+AIX+Windows),
> Carbon seemed like a good choice.
> Now we have just wasted several man years going to Cocoa.
> Microsoft is really the good guys, as somebody said, not letting developers 
> down.
> /Lars

Does anyone remember when Cocoa / Carbon / Java were all supposed to be valid 
paths forward on OS X?

A quick search turned up...
http://ec30.org/skills/mac-os-x-carbon-cocoa-development/ 


Notice the application frameworks in the image at the front.

It wasn’t always clear that Cocoa was going to be the last man standing on OS X.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 4, 2019, at 12:41 PM, Lars C. Hassing via Cocoa-dev 
>  wrote:
> 
>   "Apple is committed to the HIViews, Carbon events, and nib files for Carbon 
> implementations of the user interface.
>All new controls and other features will be based on HIView.
>If you want your application to take advantage of the latest features, you 
> need to adopt the modern HIToolbox.”

If you look at the wording, this was telling Carbon developers they needed to 
update to HIViews, Carbon events and nib files. Not telling developers Apple 
was committed to Carbon forever.

And this was 15 years ago. A few years later (still over 10 years ago) Apple 
deprecated HIToolbox and it was pretty clear that Cocoa was the way forward.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Lars C. Hassing via Cocoa-dev]

On 4 Oct 2019, at 21.00, Jens Alfke wrote:

The people I hear complaining about this are those who, like you, didn't move 
to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac 
OS X shipped in March 2001, but even though it wasn't yet formally deprecated, 
it was clear it would be.

Carbon might have started as a temporary solution, but it ended up a very good 
solution,
which Apple stated in "It’s the Future” (Last updated: 2004-06-28)

   "Apple is committed to the HIViews, Carbon events, and nib files for Carbon 
implementations of the user interface.
All new controls and other features will be based on HIView.
If you want your application to take advantage of the latest features, you 
need to adopt the modern HIToolbox.”

https://web.archive.org/web/20080725021421/http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/upgrading_hitoolbox_conc/chapter_2_section_7.html


When my company was going to the Mac platform (in addition to Sun+AIX+Windows),
Carbon seemed like a good choice.
Now we have just wasted several man years going to Cocoa.
Microsoft is really the good guys, as somebody said, not letting developers 
down.
/Lars

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Turtle Creek Software via Cocoa-dev]

>> If you’re finding it difficult in the various transitions going on, how
about reaching out to another developer or group to get you over those
hurdles?

If only it were that simple.  Cocoa wasn't just a few hurdles.  More like a
constant slog of small and medium-sized problems, with insufficient tools
to solve them. Usually Stack Overflow, books and blogs are enough.  But
anything before 2010 was severely outdated, and anything after 2014 was
Swift rather than Obj-C.  The window was too narrow.

Here is a brief history of TurtleSoft, so you can see where we're coming
from.

We started in 1987 with Excel templates for construction companies,
originally made for Turtle Creek Carpentry. Sales were 100% Mac for the
first couple years, then 50/50 after Windows 3.0.  MacNail was very
profitable.  We also wrote a HyperCard based construction estimator, which
was OK but less successful.

First prototype of our current accounting/estimating app was about 1992, in
Think Pascal with Think Class Library.  We abandoned that when Apple
pivoted to C++ and PPC.  Version 1.0 then took about 15 programmer-years to
write, in C++/Codewarrior/PowerPlant.  Shipped late 2000. The first 10 were
easy because of good income from the templates. 3 programmers plus support
staff. Then Apple lost $1 billion and almost died, and our sales dropped
50%, then more. The next 5 programmer-years happened on credit card debt
and desperation.  TurtleSoft had to downsize to survive it.

2001 to 2013 was spent fixing bugs, adding features, marketing, paying off
debts, having a life again. Another 5 programmer-years to get a really
well-polished app.  During that time, updating to Carbon took a few
programmer-months, thanks to good tools from Metrowerks.  Updating to Intel
was also easy, since we already had byte-swapping for the Windows version.
Giving up CodeWarrior and enduring Xcode 3.0 was the hardest part.

During that time there was no time or cash for a major rewrite to Cocoa.
Just not possible. There were bigger concerns.

Updating the C++ to 64-bit took 2 programmer-years, 2013 to 2015.  Removing
most of PowerPlant, switching from LArray to std::vector, writing an object
database to replace the crappy licensed one.  That was productive work,
applicable to both Mac & Win. Construction companies don't need 4GB files,
but we also use the same code for a gene/protein app.  One human genome is
750MB minimum, so that version needs bigger files.

The plan was to subcontract the Cocoa conversion in parallel. We assumed
there would be tons of experienced Carbon->Cocoa programmers so late in the
game who could whip it out in a year or less. The bigger offshore subs
would only touch it on an hourly basis, estimated $100K to $200K.  One QT
guy quoted $30K for both platforms, which was pretty much our maximum
budget. He took the first draw payment then failed.  3 others tried pure
Cocoa for a similar price, but got nowhere.

In 2015 we finished the 64-bit prep, and started work on Cocoa in-house.
Based on past updates, 4 years seemed like plenty of time.  Now, after 2 or
3 programmer-years, a realistic guess is another 2 or 3 needed to finish.
Our app has a lot of interface code.  Running a construction business is
complicated.  We do a lot more than QuickBooks.

Since 2001, sales have been 36% Mac, 64% Windows.  It's really just math.
Another 2 or 3 programmer-years on Cocoa, just in time for Apple to make
another big pivot.  Versus 1 year for MFC code that will last 10 or 20
years, and have twice the sales.  Maybe we'll come back and do Mac later.
Maybe not.

In general, our lives would sure be easier and the business more
profitable, if we could create good software in less time.  I have some
ideas on how Apple could make that happen with Cocoa, based on the problems
we had with it. But I will wait to see if it's OK to talk about it here.
Post-mortems can be educational, if not classed as whining.

Casey McDermott
TurtleSoft.com



On Fri, Oct 4, 2019 at 11:04 AM Gary L. Wade 
wrote:

> If you’re finding it difficult in the various transitions going on, how
> about reaching out to another developer or group to get you over those
> hurdles?  I used to work with a number of guys who are part of
> http://orderndev.com/ and while I’ve not kept up with them lately, they
> should be able to help in some way.  I worked with them in the Classic days
> and the early Carbon days, and they’ve also worked on a number of Cocoa
> projects after that time, too.  I don’t know their rates or availability,
> but maybe reaching out to them might get you to the next level?  BTW
> they’re also very familiar with projects that transitioned out of existence
> as they also worked on OpenDoc and even presented about it at WWDC.
> --
> Gary L. Wade
> http://www.garywade.com/
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators 

Re: Thoughts on Cocoa

[Richard Charles via Cocoa-dev]

> On Oct 4, 2019, at 4:43 AM, Dragan Milić via Cocoa-dev 
>  wrote:
> 
> Apple also strongly and clearly advised all new development should be done in 
> Yellow Box/Cocoa. Sure it took Apple too quite some time to transition 
> everything away from Carbon, but it was clear from the beginning that Carbon 
> was there just as long as it was really needed, and not a minute longer. With 
> every early major releases (until 2007) of macOS, Apple put strong emphasis 
> in release notes which OS-bundled applications have gone from Carbon to Cocoa.

I don’t think it was this clear. I remember reading an Apple employment 
advertisement roughly around 2005 that went something like this. "Join the 
engineering team and help us make the next Finder rewrite the absolute best 
ever with Carbon and C++.” It was reported that Apple had the 64 bit Carbon 
port done when the decision was made not to release the product but rather 
focus the company's resources and efforts on Cocoa instead. It appears there 
was a lot of internal turmoil within the company and the resistance to Cocoa 
was strong but eventually Cocoa won out the day because it is a superior 
technology.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jeremy Hughes via Cocoa-dev]

> On 4 Oct 2019, at 11:43, Dragan Milić via Cocoa-dev 
>  wrote:
> 
>> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote:
>> 
>> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 
>> 2007, when Apple suddenly abandoned 64-bit Carbon.
> 
> I don’t agree.

Maybe it was clear to you, but it wasn’t clear to us. The company I work for 
sent developers to WWDC, and the message they came back with was that Carbon 
was a serious alternative to Cocoa. Of course, Apple changed its plans several 
times during this period, but the abandonment of 64-bit Carbon - after it had 
already been developed - was sudden and unexpected (to us).

It’s ancient history now. I wish Apple had given a clearer message and provided 
an easier transition. Carbon provided an easy way to transition from classic 
macOS, but there wasn’t an easy way to transition from Carbon to Cocoa.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Dragan Milić via Cocoa-dev]

> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote:
> 
> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 
> 2007, when Apple suddenly abandoned 64-bit Carbon.

I don’t agree. The first version of macOS predecessor (Rhapsody) shipped only 
with “Yellow Box” (which became “Cocoa”) API . The first version of “Blue Box” 
(which became “Carbon”) API was introduced a bit later, with specific note it’s 
a transitional API, being there to make existing MacOS (8/9) applications run 
on Rhapsody without, or with small, modifications. And that was introduced only 
after Apple realised developers aren’t ready to jump on “Yellow Box” just like 
that, no matter how great (for the time) it was.

Apple also strongly and clearly advised all new development should be done in 
Yellow Box/Cocoa. Sure it took Apple too quite some time to transition 
everything away from Carbon, but it was clear from the beginning that Carbon 
was there just as long as it was really needed, and not a minute longer. With 
every early major releases (until 2007) of macOS, Apple put strong emphasis in 
release notes which OS-bundled applications have gone from Carbon to Cocoa.

-- Dragan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jeremy Hughes via Cocoa-dev]

Hi Jens,

> On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev  
> wrote:
> 
> The people I hear complaining about this are those who, like you, didn't move 
> to Cocoa. Carbon was a _temporary_ transition API*. 

It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 
2007, when Apple suddenly abandoned 64-bit Carbon.

That might have been a good decision from Apple’s perspective, but we found it 
was extremely difficult to convert a large Carbon (C++) program into a Cocoa 
(C++ / ObjC) program. We attempted to do this (starting in 2007) and we failed. 
There were various reasons for this failure - but in the end (starting in 2017) 
we decided to do a complete rewrite using Cocoa and Swift.

I know there are large companies that successfully moved from Carbon to Cocoa, 
including Apple itself. iTunes and the Finder became Cocoa programs at some 
point. But I don’t think it was easy for small companies with large/complex 
programs.

Personally, I think that Cocoa is a much better framework than Carbon ever was. 
But I wish that Apple had made it easier to transition from Carbon to Cocoa.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Turtle Creek Software via Cocoa-dev]

I stirred up some conflict on this list. It may be because of readership
differences.

If you work for Apple or a big corp, then technical answers is what you can
offer or desire.
The big picture is someone else's worry.  When programming tools change,
it's just job security.

For a small developer, the big picture is way more important. Changes in
Cocoa can
be life or death for your app and your livelihood.  For freelancers, it's
somewhere in
between.  Change is job security, but not if it kills your client
businesses.

In the early 90s, Apple had an AEC specialist (architects, engineers &
construction).
They gave marketing help and listened to AEC developers.  Apple had a booth
at the NAHB
Homebuilder's show for a few years, with many small-to-medium developers
there.
TurtleSoft also had a line to a few other Apple employees.  Those channels
all disappeared
when Apple almost died, and they didn't come back afterwards.

Maybe this list can help with all types of communication.  Or maybe it
should just be
tech-only.  What do the current moderators think?

Casey McDermott
TurtleSoft.com

On Thu, Oct 3, 2019 at 3:04 PM Jens Alfke  wrote:

>
>
> On Oct 2, 2019, at 10:14 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> For
> anyone smaller, it's hard to justify the constant need to rewrite code just
> to stay in the same place. Return on investment is just not there.  Seems
> like each new update is more difficult.
>
>
> The people I hear complaining about this are those who, like you, didn't
> move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary
> when Mac OS X shipped in March 2001, but even though it wasn't yet formally
> deprecated, it was clear it would be. The Carbon UI frameworks were
> deprecated circa, um, 2006(?). QuickTime has been deprecated nearly as
> long. 64-bit systems shipped in the mid-2000s, even before the x86
> transition, and it was obvious then that 32-bit would eventually go away.
>
> Eighteen years is _forever_ in the tech industry. At the time Cocoa was
> introduced, the Mac itself hadn't even been around that long!
>
> It sounds like keeping an app limping along on 30-year-old APIs, and then
> suddenly trying to move it forwards all at once, is a bad idea. By
> comparison, keeping a Cocoa app up to date isn't that big a deal. I was
> maintaining Cocoa apps during the 64-bit, x86 and ARC transitions and had
> to make very few code changes. I've been out of the UI world for about 8
> years, and there have definitely been significant changes in areas like
> view layout and document handling, but adapting to those isn't rocket
> science.
>
> Yes, Microsoft is rather fanatical about compatibility. But that's part of
> what lost them their lead after the '90s: the amount of development
> resources needed to keep everything working exactly the same, and the
> difficulty of making forward progress without breaking any apps.
>
> —Jens
>
> * Yes it was. I was working at Apple and involved in the Carbon transition
> during 1999-2000.
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 2, 2019, at 10:14 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> For
> anyone smaller, it's hard to justify the constant need to rewrite code just
> to stay in the same place. Return on investment is just not there.  Seems
> like each new update is more difficult.

The people I hear complaining about this are those who, like you, didn't move 
to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac 
OS X shipped in March 2001, but even though it wasn't yet formally deprecated, 
it was clear it would be. The Carbon UI frameworks were deprecated circa, um, 
2006(?). QuickTime has been deprecated nearly as long. 64-bit systems shipped 
in the mid-2000s, even before the x86 transition, and it was obvious then that 
32-bit would eventually go away.

Eighteen years is _forever_ in the tech industry. At the time Cocoa was 
introduced, the Mac itself hadn't even been around that long!

It sounds like keeping an app limping along on 30-year-old APIs, and then 
suddenly trying to move it forwards all at once, is a bad idea. By comparison, 
keeping a Cocoa app up to date isn't that big a deal. I was maintaining Cocoa 
apps during the 64-bit, x86 and ARC transitions and had to make very few code 
changes. I've been out of the UI world for about 8 years, and there have 
definitely been significant changes in areas like view layout and document 
handling, but adapting to those isn't rocket science.

Yes, Microsoft is rather fanatical about compatibility. But that's part of what 
lost them their lead after the '90s: the amount of development resources needed 
to keep everything working exactly the same, and the difficulty of making 
forward progress without breaking any apps.

—Jens

* Yes it was. I was working at Apple and involved in the Carbon transition 
during 1999-2000.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Flavio Donadio via Cocoa-dev]

If...

... the new platform-specific APIs are just that: platform-specific;

... there’s a way to integrate Swift code in Objective-C apps (and, I presume, 
Objective-C++ too);

... the most common complaint is about keeping code cross-platform;

Then what is the problem with new, platform-specific APIs being Swift-only?


Regards,
Flavio 

Enviado do meu iPhone

Em 2 de out de 2019, à(s) 19:07, Gerald Henriksen  escreveu:

> On Wed, 02 Oct 2019 15:19:43 -0400, you wrote:
> 
>> Don’t worry, ObjC UI is not being deprecated.  There are new APIs in 
>> Catalina that are Swift-only, but that does not and will not prevent you 
>> from continuing to write ObjC applications that simply don’t use those 
>> APIs. 
> 
> Apple may not (yet) be deprecating ObjC, but the fact that any new
> stuff is Swift only inherently puts any developers/companies using
> ObjC (either by choice, or by necessity if using a C++ codebase) at a
> competitive disadvantage against any apps/companies that can go with
> Swift.
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Dragan Milić via Cocoa-dev]

> čet 03.10.2019., at 10.53, Matthew Kozak via Cocoa-dev wrote:
> 
> Well, actually:
> http://www.eat-more-burgers.com/blog/drugstore-burger
> (couldn't resist).
> 
> Maybe more like going to a drug's manufacturing plant to complain about your 
> PBM (pharmacy benefits manager), but yeah.

Touché!

-- Dragan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Matthew Kozak via Cocoa-dev]

Well, actually:
http://www.eat-more-burgers.com/blog/drugstore-burger
(couldn't resist).

Maybe more like going to a drug's manufacturing plant to complain about your 
PBM (pharmacy benefits manager), but yeah.


-Matt


From: Cocoa-dev  on 
behalf of Dragan Milić via Cocoa-dev 
Sent: Thursday, October 3, 2019 4:43 AM
To: Cocoa-dev 
Subject: Re: Thoughts on Cocoa

> čet 03.10.2019., at 00.49, John Randolph via Cocoa-dev wrote:
>
> Speaking as a former moderator of this list, this thread is off-topic for 
> Cocoa-dev.  This list is for TECHNICAL discussion and help.
> Kindly take it to reddit or wherever else the denizens of 
> comp.sys.mac.advocacy ended up.

This whining crap seem to be appearing on the list every now and then, with 
mostly the same participants. While I may or may not agree with some or all of 
your points, This is not the place for that! Do you regularly go to the 
pharmacy and ask for double cheese burger in there?

-- Dragan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apple.com%2Fmailman%2Foptions%2Fcocoa-dev%2Fmkozak%2540oit.rutgers.edudata=02%7C01%7Cmkozak%40oit.rutgers.edu%7Cc722025aac1443b003d108d747dddc86%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C637056890537780543sdata=Cp195jEtrxl4m6AvK3JikmgC%2BX9woBlb8AGAibohOdc%3Dreserved=0

This email sent to mko...@oit.rutgers.edu
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Dragan Milić via Cocoa-dev]

> čet 03.10.2019., at 00.49, John Randolph via Cocoa-dev wrote:
> 
> Speaking as a former moderator of this list, this thread is off-topic for 
> Cocoa-dev.  This list is for TECHNICAL discussion and help. 
> Kindly take it to reddit or wherever else the denizens of 
> comp.sys.mac.advocacy ended up.

This whining crap seem to be appearing on the list every now and then, with 
mostly the same participants. While I may or may not agree with some or all of 
your points, This is not the place for that! Do you regularly go to the 
pharmacy and ask for double cheese burger in there?

-- Dragan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[John Randolph via Cocoa-dev]

Speaking as a former moderator of this list, this thread is off-topic for 
Cocoa-dev.  This list is for TECHNICAL discussion and help. 

Kindly take it to reddit or wherever else the denizens of comp.sys.mac.advocacy 
ended up.

-jcr

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jeff Evans via Cocoa-dev]

Well,  hey, we here use Cocoa and are prepared for 64-bit as of the next couple 
of weeks.
But that’s about basic changes in chip architecture and is understandable. I 
was more worried about any hints of leaving Obj-C behind, and I’m glad to hear 
that the Obj-C interface will continue to be valid for the existing API.

Jeff

On Oct 2, 2019, at 3:37 PM, Rick Mann via Cocoa-dev  
wrote:

You guys have had *YEARS* to get your code bases updated to more modern APIs 
and architectures. All this whining is bullshit. You've deferred and delayed 
those updates and despite constant warnings that 32-bit was being deprecated, 
you haven't updated.

As a user of some apps, I'm pissed. As a developer, I know it was on me to keep 
up.

This wasn't a surprise.

-- 
Rick Mann
rm...@latencyzero.com




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Rick Mann via Cocoa-dev]

You guys have had *YEARS* to get your code bases updated to more modern APIs 
and architectures. All this whining is bullshit. You've deferred and delayed 
those updates and despite constant warnings that 32-bit was being deprecated, 
you haven't updated.

As a user of some apps, I'm pissed. As a developer, I know it was on me to keep 
up.

This wasn't a surprise.

-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Gerald Henriksen via Cocoa-dev]

On Wed, 02 Oct 2019 15:19:43 -0400, you wrote:

>Don’t worry, ObjC UI is not being deprecated.  There are new APIs in 
>Catalina that are Swift-only, but that does not and will not prevent you 
>from continuing to write ObjC applications that simply don’t use those 
>APIs. 

Apple may not (yet) be deprecating ObjC, but the fact that any new
stuff is Swift only inherently puts any developers/companies using
ObjC (either by choice, or by necessity if using a C++ codebase) at a
competitive disadvantage against any apps/companies that can go with
Swift.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Marco S Hyman via Cocoa-dev]

On Oct 2, 2019, at 1:15 PM, Sam Ryan via Cocoa-dev  
wrote:
> 
> It has felt like the support is not there the
> last few years, with much of the documentation "archived" and the new
> documentation focused on Swift.

While the text in the doc window shows me the Swift version I can always click 
on the Objective-C language selection to see the Objective-C version.  Unless 
I’m looking at something newish which doesn’t exist in Objective-C, e.g. the 
Combine framework.

I’ve assumed that the doc window shows me Swift because I’m coding in swift.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Sam Ryan via Cocoa-dev]

It is good to know there is still solid support for Objective-C UI, thank
you for the information John. It has felt like the support is not there the
last few years, with much of the documentation "archived" and the new
documentation focused on Swift. Presently, it is hard to justify native
development on macOS because there is very little information and a lot of
uncertainty about the future. Simply predicting how much upkeep will be
required to keep an application running for 5 years is a tough question to
answer. When justifying a redevelopment or a new project, the native macOS
option is very low in the list of options because of this.

From a user's perspective, dropping 32-bit is the reason that I will
probably not update to Catalina any time soon. I rely on older pieces of
software, and there's a few games I enjoy which will no longer work.
Upgrading will simply get in the way of what I want to do. Never say never
though, 10.16 might have some amazing feature I can't be without, like dark
mode 2.0, and I'll be forced to upgrade!



On Thu, 3 Oct 2019 at 08:19, John McCall via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> On 2 Oct 2019, at 15:03, Jeff Evans via Cocoa-dev wrote:
> > Here’s another small developer’s perspective:
> >   Practica Musica has been around since 1987 in one form or another
> > (originally in 68000 assembler!). We’ve sold a lot of Macs for
> > Apple.  The upcoming version 7 is still C++ with Objective-C where
> > necessary for the UI. We refuse to use Swift, another
> > platform-specific language: the project is very large and we can’t
> > rewrite hundreds of files on a whim.  Swift may be nice, but it’s
> > not necessary.
> >   I haven’t been paying close attention and can’t tell if the
> > concern in this discussion is over any hints that Apple might again
> > force a major change on existing apps, but if there have been such
> > hints let me add another voice to the chorus: Apple really needs to
> > keep its installed base.
> >   The new Windows version of Practica Musica is 100% plain old C++,
> > using Microsoft’s new C++/winrt, so mostly only the UI classes
> > differ from the Mac version. That is a clean, easy, fast system and I
> > can trust them not to abandon it any time soon. Using their new system
> > was entirely voluntary; the old ways are still viable but the new one
> > is just better.
> >   I hope Apple can borrow that attitude from MS.  I worry about
> Apple
> > pulling the rug out from under our Mac projects somewhere down the
> > line. If they do we’ll have to abandon the platform, with great
> > regrets. Switching to Intel chips was unavoidable; we understood that;
> > but if, for example,  they deprecate the existing Obj-C UI they’ll
> > leave a lot of installed base behind.
>
> Don’t worry, ObjC UI is not being deprecated.  There are new APIs in
> Catalina that are Swift-only, but that does not and will not prevent you
> from continuing to write ObjC applications that simply don’t use those
> APIs.  Apple is well aware that ObjC is a core language for most of our
> developer community, and that even developers who are primarily writing
> new code in Swift are usually integrating that into substantial bodies
> of existing ObjC code.
>
> Catalina does drop support for 32-bit applications.  Since Carbon has
> never been supported on 64-bit macOS, this means that Carbon is no
> longer supported, after 7 years of formal deprecation and a few more
> years of “writing on the wall”.  That is what some people are upset
> about.
>
> John.
>
> >
> >   Jeff Evans
> >
> >
> >
> > On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev
> >  wrote:
> >
> >
> >> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev
> >>  wrote:
> >>
> >> Sadly, we just decided to abandon the Cocoa update for our app.
> >
> > Great historical overview from a small developers perspective. Perhaps
> > you should send this email to Tim Cook. It might some attention. Just
> > a thought.
> >
> > --Richard Charles
> >
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/jevans%40ars-nova.com
> >
> > This email sent to jev...@ars-nova.com
> >
> >
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/rjmccall%40apple.com
> >
> > This email sent to rjmcc...@apple.com
> ___
>
> Cocoa-dev mailing list 

Re: Thoughts on Cocoa

[John McCall via Cocoa-dev]

On 2 Oct 2019, at 15:03, Jeff Evans via Cocoa-dev wrote:

Here’s another small developer’s perspective:
	Practica Musica has been around since 1987 in one form or another 
(originally in 68000 assembler!). We’ve sold a lot of Macs for 
Apple.  The upcoming version 7 is still C++ with Objective-C where 
necessary for the UI. We refuse to use Swift, another 
platform-specific language: the project is very large and we can’t 
rewrite hundreds of files on a whim.  Swift may be nice, but it’s 
not necessary.
	I haven’t been paying close attention and can’t tell if the 
concern in this discussion is over any hints that Apple might again 
force a major change on existing apps, but if there have been such 
hints let me add another voice to the chorus: Apple really needs to 
keep its installed base.
	The new Windows version of Practica Musica is 100% plain old C++, 
using Microsoft’s new C++/winrt, so mostly only the UI classes 
differ from the Mac version. That is a clean, easy, fast system and I 
can trust them not to abandon it any time soon. Using their new system 
was entirely voluntary; the old ways are still viable but the new one 
is just better.
	I hope Apple can borrow that attitude from MS.  I worry about Apple 
pulling the rug out from under our Mac projects somewhere down the 
line. If they do we’ll have to abandon the platform, with great 
regrets. Switching to Intel chips was unavoidable; we understood that; 
but if, for example,  they deprecate the existing Obj-C UI they’ll 
leave a lot of installed base behind.


Don’t worry, ObjC UI is not being deprecated.  There are new APIs in 
Catalina that are Swift-only, but that does not and will not prevent you 
from continuing to write ObjC applications that simply don’t use those 
APIs.  Apple is well aware that ObjC is a core language for most of our 
developer community, and that even developers who are primarily writing 
new code in Swift are usually integrating that into substantial bodies 
of existing ObjC code.


Catalina does drop support for 32-bit applications.  Since Carbon has 
never been supported on 64-bit macOS, this means that Carbon is no 
longer supported, after 7 years of formal deprecation and a few more 
years of “writing on the wall”.  That is what some people are upset 
about.


John.



Jeff Evans



On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev 
 wrote:



On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev 
 wrote:


Sadly, we just decided to abandon the Cocoa update for our app.


Great historical overview from a small developers perspective. Perhaps 
you should send this email to Tim Cook. It might some attention. Just 
a thought.


--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/jevans%40ars-nova.com

This email sent to jev...@ars-nova.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/rjmccall%40apple.com

This email sent to rjmcc...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Jeff Evans via Cocoa-dev]

Here’s another small developer’s perspective:
Practica Musica has been around since 1987 in one form or another 
(originally in 68000 assembler!). We’ve sold a lot of Macs for Apple.  The 
upcoming version 7 is still C++ with Objective-C where necessary for the UI. We 
refuse to use Swift, another platform-specific language: the project is very 
large and we can’t rewrite hundreds of files on a whim.  Swift may be nice, but 
it’s not necessary.
I haven’t been paying close attention and can’t tell if the concern in 
this discussion is over any hints that Apple might again force a major change 
on existing apps, but if there have been such hints let me add another voice to 
the chorus: Apple really needs to keep its installed base.
The new Windows version of Practica Musica is 100% plain old C++, using 
Microsoft’s new C++/winrt, so mostly only the UI classes differ from the Mac 
version. That is a clean, easy, fast system and I can trust them not to abandon 
it any time soon. Using their new system was entirely voluntary; the old ways 
are still viable but the new one is just better.
I hope Apple can borrow that attitude from MS.  I worry about Apple 
pulling the rug out from under our Mac projects somewhere down the line. If 
they do we’ll have to abandon the platform, with great regrets. Switching to 
Intel chips was unavoidable; we understood that; but if, for example,  they 
deprecate the existing Obj-C UI they’ll leave a lot of installed base behind. 

Jeff Evans



On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev 
 wrote:


> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Sadly, we just decided to abandon the Cocoa update for our app.

Great historical overview from a small developers perspective. Perhaps you 
should send this email to Tim Cook. It might some attention. Just a thought.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/jevans%40ars-nova.com

This email sent to jev...@ars-nova.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Carl Hoefs via Cocoa-dev]

> On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Sadly, we just decided to abandon the Cocoa update for our app.
> 
> Great historical overview from a small developers perspective. Perhaps you 
> should send this email to Tim Cook. It might some attention. Just a thought.
> 

Not likely... The Apple people I know say that Tim Cook is John Sculley II. Why 
do you think Jony Ive left?
-Carl


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Pier Bover via Cocoa-dev]

I much prefer the Microsoft approach here. I guess the lesson to be learned
is to depend as less as possible on Apple or either be forced to go through
all the frequent SDK and language changes.

I'm planning on working on a desktop project and looking for solution to
use Cocoa/Swift as less as possible. For the UI I can use a web view which
works for my use case. I can also use cross platform modules with languages
like C++, C, or Nim. Another option would be using QT.

If developing a new product I would also seriously consider if it can work
on the browser as a web app. Development is much easier in my experience
than mobile/desktop apps.

On Wed, Oct 2, 2019 at 12:15 PM Turtle Creek Software via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> Sadly, we just decided to abandon the Cocoa update for our app. It's not
> easy to walk away from 3 years of work, but better 3 years lost than 5.
> Time will be better spent on our Windows version.
>
> TurtleSoft started Mac-only with Excel templates in 1987. The first
> prototype of our current stand-alone accounting app was in the early 90s.
> Since then, programming for Mac has gone through four primary programming
> languages (Pascal, C++, Objective C, Swift).  Three, soon to be four chip
> architectures (680x0, PPC, Intel, ARM).  Four frameworks (MacApp or Think
> Class Library, PowerPlant, Carbon, Cocoa).
>
> Microsoft and Adobe are big enough that they've survived the many pivots.
> They can just throw 100 programmers at it. Intuit has barely kept up. For
> anyone smaller, it's hard to justify the constant need to rewrite code just
> to stay in the same place. Return on investment is just not there.  Seems
> like each new update is more difficult.
>
> Many good apps for Mac have died in one pivot or another.  We managed to
> lurch through most of the changes, but not this one.  Thinking ahead to the
> consequences of Marzipan was the last straw.
>
> Meanwhile, our Windows version hasn't needed any work since 2000. It
> probably will take less than a year to get it updated to 64-bit and a
> better interface.
>
> Casey McDermott
> TurtleSoft.com
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/pierbover11%40gmail.com
>
> This email sent to pierbove...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[David M. Cotter via Cocoa-dev]

agreed.  i'm a small one person company with about ten of thousand customers, 
half mac half windows.

wrote for mac first, carbon C++
ported to windows by porting CoreFoundation, then simulating Carbon APIs for 
everything else

it's taken me YEARS to try to switch to Cocoa, and i'm still not done. when 
Catalina comes out, i will be UNABLE to sell on new macs, and unable to run on 
customers who choose to upgrade, all because Apple abandoned Carbon in 32bits 
(if i remember correctly, apple HAD a 64bit port for carbon but chose not to 
release it)

my app also depended on QuickTime, which is now dead, forcing an entire rewrite 
of my media player engine.

i keep having to rewrite things because apple makes promises, which i trust 
then come to depend on, then Apple breaks those promises, forcing years worth 
of work for me JUST to tread water.

my current windows app STILL WORKS ON VISTA, i don't have to do ANYTHING to 
"stay up to date" with Windows, cuz they support backward compatibility, and 
don't force changes on developers.

MS used to be the bad guy, and Apple the good guy.  

how times have changed.

> On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Sadly, we just decided to abandon the Cocoa update for our app.
> 
> Great historical overview from a small developers perspective. Perhaps you 
> should send this email to Tim Cook. It might some attention. Just a thought.
> 
> --Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Thoughts on Cocoa

[Richard Charles via Cocoa-dev]

> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Sadly, we just decided to abandon the Cocoa update for our app.

Great historical overview from a small developers perspective. Perhaps you 
should send this email to Tim Cook. It might some attention. Just a thought.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com