Re: Future of Cocoa

[Saagar Jha via Cocoa-dev]

Now that I think about it, you can probably do this without support from the 
runtime by interposing the handful of runtime functions that invalidate the 
method cache…

Saagar Jha

> On Dec 16, 2019, at 00:23, Jean-Daniel  wrote:
> 
> My bad, I just see that when rereading the description. Of course, it will 
> requires an updated runtime.
> 
>> Le 16 déc. 2019 à 09:21, Saagar Jha > > a écrit :
>> 
>> There’s also a check for method swizzling and other invalidation, assuming 
>> that there is cooperation from the runtime. Unless I’m misunderstanding what 
>> you mean by the selector changing?
>> 
>> Saagar Jha
>> 
>>> On Dec 16, 2019, at 00:16, Jean-Daniel >> > wrote:
>>> 
>>> 
 Le 16 déc. 2019 à 06:05, Saagar Jha >>> > a écrit :
 
 It’s been a while, but I just thought you both might be interested in some 
 follow-up I did for this idea. I implemented it for fun in clang 
  and it turns out that it’s a 
 pretty decent performance win 
  over 
 objc_msgSend, both because it dispatches faster and because the compiler 
 can do a full inline through it.
>>> 
>>> Yes, but you don't preserve the objc_msgSend semantic.
>>> 
>>> If I understand you code correctly, all you do is checking if it is the 
>>> same ISA, which does not guarantee in anyway that the selector did not 
>>> change since the previous call.  
>>> 
>>> As classes are fully dynamic and methods can be swizzle, you must perform a 
>>> full IMP lookup for every calls, which complexly defeat the purpose of 
>>> inline caching.
>>> 
>> 
> 

___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

My bad, I just see that when rereading the description. Of course, it will 
requires an updated runtime.

> Le 16 déc. 2019 à 09:21, Saagar Jha  a écrit :
> 
> There’s also a check for method swizzling and other invalidation, assuming 
> that there is cooperation from the runtime. Unless I’m misunderstanding what 
> you mean by the selector changing?
> 
> Saagar Jha
> 
>> On Dec 16, 2019, at 00:16, Jean-Daniel > > wrote:
>> 
>> 
>>> Le 16 déc. 2019 à 06:05, Saagar Jha >> > a écrit :
>>> 
>>> It’s been a while, but I just thought you both might be interested in some 
>>> follow-up I did for this idea. I implemented it for fun in clang 
>>>  and it turns out that it’s a 
>>> pretty decent performance win 
>>>  over 
>>> objc_msgSend, both because it dispatches faster and because the compiler 
>>> can do a full inline through it.
>> 
>> Yes, but you don't preserve the objc_msgSend semantic.
>> 
>> If I understand you code correctly, all you do is checking if it is the same 
>> ISA, which does not guarantee in anyway that the selector did not change 
>> since the previous call.   
>> 
>> As classes are fully dynamic and methods can be swizzle, you must perform a 
>> full IMP lookup for every calls, which complexly defeat the purpose of 
>> inline caching.
>> 
> 

___

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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

There’s also a check for method swizzling and other invalidation, assuming that 
there is cooperation from the runtime. Unless I’m misunderstanding what you 
mean by the selector changing?

Saagar Jha

> On Dec 16, 2019, at 00:16, Jean-Daniel  wrote:
> 
> 
>> Le 16 déc. 2019 à 06:05, Saagar Jha > > a écrit :
>> 
>> It’s been a while, but I just thought you both might be interested in some 
>> follow-up I did for this idea. I implemented it for fun in clang 
>>  and it turns out that it’s a 
>> pretty decent performance win 
>>  over 
>> objc_msgSend, both because it dispatches faster and because the compiler can 
>> do a full inline through it.
> 
> Yes, but you don't preserve the objc_msgSend semantic.
> 
> If I understand you code correctly, all you do is checking if it is the same 
> ISA, which does not guarantee in anyway that the selector did not change 
> since the previous call.
> 
> As classes are fully dynamic and methods can be swizzle, you must perform a 
> full IMP lookup for every calls, which complexly defeat the purpose of inline 
> caching.
> 

___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 16 déc. 2019 à 06:05, Saagar Jha  a écrit :
> 
> It’s been a while, but I just thought you both might be interested in some 
> follow-up I did for this idea. I implemented it for fun in clang 
>  and it turns out that it’s a 
> pretty decent performance win 
>  over 
> objc_msgSend, both because it dispatches faster and because the compiler can 
> do a full inline through it.

Yes, but you don't preserve the objc_msgSend semantic.

If I understand you code correctly, all you do is checking if it is the same 
ISA, which does not guarantee in anyway that the selector did not change since 
the previous call.  

As classes are fully dynamic and methods can be swizzle, you must perform a 
full IMP lookup for every calls, which complexly defeat the purpose of inline 
caching.

___

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: Future of Cocoa #2

[Charles Srstka via Cocoa-dev]

> On Dec 10, 2019, at 5:57 PM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Xojo is new to me, but it appears more a SwiftUI than a Cocoa substitute.

Xojo is just the new name for RealBASIC, which has been around forever.

It wouldn’t be my first choice.

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: Future of Cocoa #2

[Tor Arne Vestbø via Cocoa-dev]

> On 11 Dec 2019, at 21:35, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> QT is probably the most viable cross-platform tool, but steep learning
>> curve and mediocre GUI.  Will it survive if Cocoa is deprecated?
> 
> Good question - I have no idea.
> 
> But I suggest you reach out to the support, or ask on Qt's forums about 
> roadmaps,
> or meet them in person at an expo/conference (I met them a few years ago at 
> Siggraph).

It will. 

Qt has survived Carbon removal, 32-bit-removal, and will stay on macOS 
regardless of the underlying Apple technologies used to implement the Qt 
platform layers.

Cheers,
Tor Arne

___

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: Future of Cocoa #2

[Gabriel Zachmann via Cocoa-dev]

> QT is probably the most viable cross-platform tool, but steep learning
> curve and mediocre GUI.  Will it survive if Cocoa is deprecated?

Good question - I have no idea.

But I suggest you reach out to the support, or ask on Qt's forums about 
roadmaps,
or meet them in person at an expo/conference (I met them a few years ago at 
Siggraph).

Best regards, Gabriel

___

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: Future of Cocoa #2

[Andreas Falkenhahn via Cocoa-dev]

On 11.12.2019 at 00:57 Turtle Creek Software via Cocoa-dev wrote:

> wxWidgets is still Carbon, with an incomplete Cocoa fork.

No, wxWidgets has a very stable, complete and usable Cocoa backend and it's not 
nearly as bloated as Qt.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Future of Cocoa #2

[Turtle Creek Software via Cocoa-dev]

>> Apple has absolutely zero need to deliver a cross-OS-platform
Totally agreed.  The issue isn't Apple vs Microsoft, it's iOS vs macOS.

>> If you're so absolutely set on cross-platform, leave the cross-platform
work to those who do that
We had a good 30-year run selling on both Mac & Windows: first with Excel,
then HyperCard/Toolbook, then C++.
But it keeps getting harder.

A great cross-platform development tool would sure be nice, but we gave up
on that hope many years ago.

Microsoft's .Net is a way to run C# programs on other platforms.  I don't
think it ever got much traction outside of Windows.
CocoTron is a way to run Objective-C programs on other platforms.  Has
anyone here used it?
wxWidgets is still Carbon, with an incomplete Cocoa fork.
Xojo is new to me, but it appears more a SwiftUI than a Cocoa substitute.
QT is probably the most viable cross-platform tool, but steep learning
curve and mediocre GUI.  Will it survive if Cocoa is deprecated?

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: Future of Cocoa #2

[Glenn L. Austin via Cocoa-dev]

> On Dec 10, 2019, at 12:58 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Dec 10, 2019, at 10:55 AM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Thoughts?
>> 
> 
> 
> What if Apple were to open source Foundation, Core Data, etc., most every 
> thing but the UI so that developers could more easily generate cross platform 
> apps.
> 
> Recently visited this Microsoft web site where the tag line is 
> "cross-platform". It would be interesting to know if this stuff really works.
> 
> https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet
> 
> --Richard Charles
> 

If you're so absolutely set on cross-platform, leave the cross-platform work to 
those who do that — and write your code to those libraries.

Here's some options: wxWidgets, Qt, Cocotron, Xojo. Each has strengths and 
weaknesses, but you're never going to get an entirely "platform native" 
experience on all platforms because each platform is *different*. The 
advantages to libraries like wxWidgets, Qt, and Xojo is that *they* do the work 
to support new technologies, the downside is that the support may take some 
time and not work exactly the same on all platforms.

MVVM might help save you, but that's basically what cross-platform libraries 
provide. You're stuck developing your own or using one of the pre-existing ones 
(and I'd suggest one of the pre-existing ones). The advantage is that the 
libraries open up options beyond "macOS" and "Windows" - the disadvantage is 
that they eliminate much of the platform-specific behaviors.

Apple has absolutely zero need to deliver a cross-OS-platform GUI toolset 
beyond macOS/iOS/tvOS/watchOS - and even then, it's likely to be based on 
SwiftUI, and not C++. It's their competitive advantage, and the reason why 
you're looking to *them* to do the work is so that you don't need to. The 
problem is that you've waited until the train has pulled into the station two 
stops after yours before deciding to jump on.

-- 
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: Future of Cocoa #2

[Richard Charles via Cocoa-dev]

> On Dec 10, 2019, at 10:55 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Thoughts?
> 


What if Apple were to open source Foundation, Core Data, etc., most every thing 
but the UI so that developers could more easily generate cross platform apps.

Recently visited this Microsoft web site where the tag line is 
"cross-platform". It would be interesting to know if this stuff really works.

https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet

--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: Future of Cocoa #2

[Steve Mills via Cocoa-dev]

> On Dec 10, 2019, at 11:56, Turtle Creek Software via Cocoa-dev 
>  wrote:

tl;dr

Oh god NOOO!

Steve via iPhone


___

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: Future of Cocoa

[Steve Mills via Cocoa-dev]

Please kill this thread. We're all sick of the constant notifications that turn 
out to only be this crap. Argue somewhere else. This is for development 
questions and getting real help.

--
Steve Mills
Drummer, Mac geek

___

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: Future of Cocoa

[Gary L. Wade via Cocoa-dev]

INCREDIBLY ridiculous! If I weren’t paid well and have a great, fulfilling job 
working on all of Apple’s platforms, I’d be tempted to make a competitive 
version of some of these develops’ apps to show how the difficulty in doing so 
is blown so out of proportion!

It sounds like some people need to join a weekend hackathon to exercise their 
skills! For a fun one, do a search for Flickr SharkFeed.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 21, 2019, at 6:02 PM, Jim Crate via Cocoa-dev 
>  wrote:
> 
> On Nov 21, 2019, at 5:43 PM, Pascal Bourguignon via Cocoa-dev 
>  wrote:
> 
>> The Apple ecosystem implies an extraordinary maintenance load. 
>> Specifically, your application must provide enough revenue to pay for a 
>> couple of developpers only to track the changes Apple makes to the API, and 
>> update it on each new version of the system (which occur about yearly).
>> So, count about 100,000 €/year to 200,000 €/year.
>> If your application doesn’t provide this profit, then you cannot follow, 
>> and it will quickly be dropped from the the AppStore.
> 
> This is pretty ridiculous.

___

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: Future of Cocoa

[Jim Crate via Cocoa-dev]

On Nov 21, 2019, at 5:43 PM, Pascal Bourguignon via Cocoa-dev 
 wrote:

> The Apple ecosystem implies an extraordinary maintenance load. 
> Specifically, your application must provide enough revenue to pay for a 
> couple of developpers only to track the changes Apple makes to the API, and 
> update it on each new version of the system (which occur about yearly).
> So, count about 100,000 €/year to 200,000 €/year.
> If your application doesn’t provide this profit, then you cannot follow, and 
> it will quickly be dropped from the the AppStore.

This is pretty ridiculous. I’ve written several custom macOS apps for a client, 
and one of the first that I wrote in 2006 has had basically a couple of 
recompiles and still works almost completely unchanged. A couple custom apps I 
inherited written in the 2000-2005 timeframe had to have some carbon stuff 
removed (FSRefs and such), and one of those is still running, although it has 
been pretty significantly updated over the years. However, these several custom 
apps (including a few iOS apps), roughly 75K lines of code total, have taken 
less than 25% of one programmer’s time to design, write, and keep relatively 
up-to-date over the last 15 years, and I’m relatively slow since I mostly use 
other languages. 

Jim Crate

___

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: Future of Cocoa

[Owen Hartnett via Cocoa-dev]

> On Nov 21, 2019, at 5:49 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> 
>> If someone can afford days/weeks to do watch WWDC sessions consistently
>> every year it's great. That's not a luxury all of us can afford and it's
>> ridiculous to think this should be a requirement.
>> 
> 
> But then, I am wondering, how does your company ensure your programmers 
> stay up-to-date?
> I have a hard time seeing how programmers can remain productive especially in 
> these days where innovation (new frameworks, new tools, new programming 
> languages) is so fast.
> 
> 

As a programmer, I do the following:

1) Keep actively coding.
2) Adopt new technologies as the times and means allow*
3) Specialize in Apple software environment.  Not enough time to do more than 
that.
4) Participate in a Mac/iOS programming meetup group
5) Watch every second of relevant WWDC videos on the train to and from work.

The reason I hitched my wagon to Apple’s star was that it was hard.  It never 
was easy to program Macs, and now devices.  Guys who can code for the hard 
stuff get the top dollar. 
Nobody will pay big bucks for a great BASIC programmer.  Or HTML, or python. 
(No shade on these platforms, they’re just …easier)

-Owen

*I’m easing my way into Swift, basically a class at a time.

-O

___

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: Future of Cocoa

[lars.sonchocky-helldorf--- via Cocoa-dev]

> Am 21.11.2019 um 23:43 schrieb Pascal Bourguignon via Cocoa-dev 
> :
> 
> Actually, things have changed. On Macintosh, basically an application 
> developed in 1984 against the Inside Macintosh (1.0) specifications still 
> worked in 1999 in the blue box with MacOS 9.1.  The platform was more stable.

Times are changing. The C64 of Commodore for instance was available basically 
unchanged for 12 years (1982 - 1994), imagine such a thing nowadays.

regards,

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 21, 2019, at 2:43 PM, Pascal Bourguignon via Cocoa-dev 
>  wrote:
> 
> Why couldn’t we have application developed once for a few users, and working 
> consistently over long periods, on a stable platform? 

Stable platforms don't make money. (Except maybe in the enterprise market where 
vendors sell support contracts for e.g. CentOS.)

> Currently the only solution would be to package such application in frozen 
> hardware and system software, which is not practical (users would need 
> different computers for each application!), and feasible (computers are not 
> really buillt to last more than a few year of usage).

Macs last quite a while. I have friends who still use ten-year-old MacBook Pros.

> Actually, things have changed. On Macintosh, basically an application 
> developed in 1984 against the Inside Macintosh (1.0) specifications still 
> worked in 1999 in the blue box with MacOS 9.1. 

We … _some_ applications still worked. Most would crash, or even bomb the 
OS, or misbehave; because they weren't 32-bit clean, or wrote directly to 
screen memory, or made assumptions about internal data structures, or etc. etc. 
etc. Even those that worked would show a black-and-white UI, often in a 
non-resizable 512x350 pixel window.

This level of backward compatibility was one of the things that crippled and 
almost killed Apple in the '90s. (I know, I was there.) It was nearly 
impossible to move the OS forward because any sort of modernization — like 
memory protection or multithreading — would break tons of apps. That's why 
"Rhapsody" failed. 

—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: Future of Cocoa

[Dragan Milić via Cocoa-dev]

> čet 21.11.2019., at 23.43, Pascal Bourguignon wrote:
> 
> It’s not like children not being happy.

That comment was related to “I’m leaving this place” announcement, probably 
because “most of you don’t agree with what I find ‘valid concerns’ so I’m 
leaving”. That’s exactly how it sounded to me.

> The Apple ecosystem implies an extraordinary maintenance load. 
> Specifically, your application must provide enough revenue to pay for a 
> couple of developpers only to track the changes Apple makes to the API, and 
> update it on each new version of the system (which occur about yearly).
> So, count about 100,000 €/year to 200,000 €/year.
> If your application doesn’t provide this profit, then you cannot follow, and 
> it will quickly be dropped from the the AppStore.
> 
> Are only applications providing good revenue worth developing and worth 
> having?
> Why couldn’t we have application developed once for a few users, and working 
> consistently over long periods, on a stable platform? 
> Currently the only solution would be to package such application in frozen 
> hardware and system software, which is not practical (users would need 
> different computers for each application!), and feasible (computers are not 
> really buillt to last more than a few year of usage).
> 
> Actually, things have changed. On Macintosh, basically an application 
> developed in 1984 against the Inside Macintosh (1.0) specifications still 
> worked in 1999 in the blue box with MacOS 9.1.  The platform was more stable.
> 
> So what can we do?

I agree with all your points. It’s not easy, i’ve never said it was. But that’s 
the matter of the fact ever since 2001. I know applications made for mac in 
1984 would still work in 1999. I know Win application made in 1995 would still 
work in 2019 (with minor or no changes at all). Would I like it to be the same 
for the modern macOS platform? I sure would! But it’s not like that and it 
hasn’t been ever since Mac OS X was officially released in 2001. It’s almost 18 
years now, that’s longer time span than 1984 - 99 and if anyone was working in 
Mac environment for that long, one should get used to it already. There’s a 
positive side of it (Apple pushing new technologies) and a negative side 
(constant updating of your software, so that it just runs normally on each new 
major OS update).

I don’t like it too, and often hate it, especially when some frameworks are 
deprecated (and later removed) without valid replacement, just because Apple 
guys think “you don’t need it and hence should not use it” (like 
LSSharedFileListItemRef and related API, for example). But even then, those 
deprecations, no matter how silent (not announced at WWDC 
keynote/platforms-state-of-the-union) are mentioned in developer's release 
notes. And only removed after a couple of next OS updates. Do you really 
consider seriously developing for a certain platform without even reading major 
OS update developer's release notes?

And then we come to those HUGE deprecations, such are Carbon, 32-bit and 
OpenGL, which were loudly announced in both Keynotes and 
platforms-state-of-the-union videos, particular developer sessions and on MANY 
places outside of WWDC, in all relevant Mac (and not only Mac, but IT and 
software dev in general related) web sites, documentation etc… And after years 
and years of getting deprecation warnings, and OS warning you about 32-bit apps 
on launch and what not, when all those are finally removed, people, who claim 
to be developers for the platform, find themselves surprised?! Sorry, call me 
stubborn, or dickhead, or whatever, but I just can’t take those people 
seriously. And then, other people use this list for what it really is meant 
for, they start posting links and advices to those who has been left behind, to 
help them to update their apps to the current APIs, and in return they get more 
complains and whining about the situation?

I mean, following the current thread, Objective-C (and after introduction of 
SwiftUI, probably AppKit/UIKit) will be declared deprecated in, say 7 - 8 years 
(just a wild guess, don’t take it seriously), and some people will ignore it 
and keep their apps tied to those APIs and technologies and when 
ObjC/AppKit/UIKit are finally removed in, like, 15 - 16 years, they will 
probably find themselves surprised (again).

-- 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: Future of Cocoa

[Gabriel Zachmann via Cocoa-dev]

> 
> If someone can afford days/weeks to do watch WWDC sessions consistently
> every year it's great. That's not a luxury all of us can afford and it's
> ridiculous to think this should be a requirement.
> 

But then, I am wondering, how does your company ensure your programmers 
stay up-to-date?
I have a hard time seeing how programmers can remain productive especially in 
these days where innovation (new frameworks, new tools, new programming 
languages) is so fast.


Best regards, Gabriel



___

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: Future of Cocoa

[Pascal Bourguignon via Cocoa-dev]

> On 21 Nov 2019, at 23:22, Dragan Milić via Cocoa-dev 
>  wrote:
> 
> And then that famous “I leave” announcement, like children not being happy 
> with how others play with them, so grabbing their toys and leave… But not 
> before making a verbal announcement about it… Well yes, good bye! What else 
> is to say? No personal or list attacks whatsoever.

It’s not like children not being happy.

The Apple ecosystem implies an extraordinary maintenance load. 
Specifically, your application must provide enough revenue to pay for a couple 
of developpers only to track the changes Apple makes to the API, and update it 
on each new version of the system (which occur about yearly).
So, count about 100,000 €/year to 200,000 €/year.
If your application doesn’t provide this profit, then you cannot follow, and 
it will quickly be dropped from the the AppStore.

Are only applications providing good revenue worth developing and worth having?
Why couldn’t we have application developed once for a few users, and working 
consistently over long periods, on a stable platform? 
Currently the only solution would be to package such application in frozen 
hardware and system software, which is not practical (users would need 
different computers for each application!), and feasible (computers are not 
really buillt to last more than a few year of usage).

Actually, things have changed. On Macintosh, basically an application developed 
in 1984 against the Inside Macintosh (1.0) specifications still worked in 1999 
in the blue box with MacOS 9.1.  The platform was more stable.


So what can we do?

Well unfortunately when we are in this situation, we must consider very 
carefully the investment on Apple platforms when developing an application.
A lot of application shouldn’t have been developed on macOS or on iOS, but on 
Linux or Android instead.  
You might have a harder time explaining it to the users, but such are the 
economic realities Apples puts us in.


-- 
__Pascal J. Bourguignon__




___

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: Future of Cocoa

[Dragan Milić via Cocoa-dev]

> čet 21.11.2019., at 23.06, Matthew Kozak wrote:
> 
> Wow.
> Debate (even heated) about Cocoa-dev (broadly) is one thing, but the personal 
> attacks, and attack on the list itself to the point of rage quitting, are all 
> unnecessary.  Before sending messages, please look in the mirror and say them 
> out loud to an actual human face and then think about it for a moment from 
> the other perspective.  It'll do a world of good and some good for the world.

No problem here to say it out loud to my own face, or anyone’s else. The 
subject has been beaten to death, in the list where it doesn’t really belong 
(not just my opinion), over and over again. People are surprised by deprecation 
of OpenGL? Really? People are surprised by deprecation of Carbon? REALLY? If, 
for example, I develop for Windows, I would make damn sure I’m up to date with 
all ongoing development and changes about the platform, because that’s my job, 
that’s the nature of the job (things constantly changing) and if I’m not happy 
about that I better be sure to try to do something else! And here people 
complain for weeks already about deprecations, which were announced YEARS ago, 
in Carbon case almost a DECADE ago. And they keep whining, like anything’s 
going to change?

And then that famous “I leave” announcement, like children not being happy with 
how others play with them, so grabbing their toys and leave… But not before 
making a verbal announcement about it… Well yes, good bye! What else is to say? 
No personal or list attacks whatsoever.

You’re welcome
-- 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: Future of Cocoa

[Matthew Kozak via Cocoa-dev]

Wow.
Debate (even heated) about Cocoa-dev (broadly) is one thing, but the personal 
attacks, and attack on the list itself to the point of rage quitting, are all 
unnecessary.  Before sending messages, please look in the mirror and say them 
out loud to an actual human face and then think about it for a moment from the 
other perspective.  It'll do a world of good and some good for the world.

Thank you,
-Matt


From: Cocoa-dev  on 
behalf of Dragan Milić via Cocoa-dev 
Sent: Thursday, November 21, 2019 4:57 PM
To: Cocoa-dev 
Subject: Re: Future of Cocoa

> ćet 21.11.2019., at 21.20, Pier Bover wrote:
>
> It's time for me to leave this mailing list.

Yeah! Good bye!
___

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.edu&data=02%7C01%7Cmkozak%40oit.rutgers.edu%7C3a56a92ab6db46c0592408d76ecdd731%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C637099702679857538&sdata=UHMASsYwVz9vGFq0dAWicJmQFWOMA945E%2FrULHp1hbE%3D&reserved=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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 21 nov. 2019 à 21:20, Pier Bover via Cocoa-dev  
> a écrit :
> 
> I won't respond each of you one by one but here are a couple of
> observations.
> 
> Metal is not a cross platform technology hence why so many projects still
> rely on OpenGL in macOS (eg: Firefox).


No, that because they don’t have enough time to migrate it to modern framework.
OpenGL is deprecated everywhere and superseded by Vulkan (which is cross 
platform and available on macOS/iOS thanks to moltenVK). 


___

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: Future of Cocoa

[Dragan Milić via Cocoa-dev]

> ćet 21.11.2019., at 21.20, Pier Bover wrote:
> 
> It's time for me to leave this mailing list.

Yeah! Good bye!
___

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: Future of Cocoa

[Gary L. Wade via Cocoa-dev]

I find the arguments here interesting. If I were to develop an OpenGL-based 
app, I would probably need at least a week to get something basic working, and 
I’m sure that applies to pretty much anyone. If someone can spend time learning 
an SDK like OpenGL, then I don’t see what’s the problem with studying anything 
else important for one’s work.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 21, 2019, at 12:21 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> I won't respond each of you one by one but here are a couple of
> observations.
> 
> Metal is not a cross platform technology hence why so many projects still
> rely on OpenGL in macOS (eg: Firefox).
> 
> I don't understand those "the writing was in the wall" type of comments.
> Even if you think something was obvious all along the indisputable truth is
> we only have guesses and rumors. It's mind blowing that anyone making
> business decisions would be ok with this uncertainty.
> 
> If someone can afford days/weeks to do watch WWDC sessions consistently
> every year it's great. That's not a luxury all of us can afford and it's
> ridiculous to think this should be a requirement.
> 
> Some will argue "just jump on SwiftUI". Well a) SwiftUI is not mature and
> b) best case scenario it will take 2-3 years before it has support for more
> than 60-70% of macOS users. In certain industries (such as audio) the
> majority of users will not update past Mojave for many years because that
> would imply letting go of expensive hardware.
> 
> Anyway, I won't be annoying you anymore with what I believe are valid
> concerns. It's time for me to leave this mailing list.
> 
> I wish you all the best.

___

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: Future of Cocoa

[Jack Brindle via Cocoa-dev]

I would add that for those of us developing for the Mac platform, the security 
sessions have been critical for the last two years. Without a good 
understanding of the issues discussed in those sessions, I don’t see how a 
developer's application could run properly on Catalina.

I see the WWDC sessions as part of my job as a Mac developer. Staying up to 
date on Mac developments is critical, otherwise I become stale and not as 
useful in my work. So, I do devote time to watching important Mac WWDC videos 
for things that I need to learn or be refreshed on.

Jack


> On Nov 21, 2019, at 1:08 PM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Nov 21, 2019, at 12:20 PM, Pier Bover via Cocoa-dev 
>>  wrote:
>> 
>> If someone can afford days/weeks to do watch WWDC sessions consistently
>> every year it's great. That's not a luxury all of us can afford and it's
>> ridiculous to think this should be a requirement.
> 
> All you need to watch are the keynote, and the "State Of The Union" talks the 
> same day. That's maybe 3-4 hours. Or if you're really short on time you can 
> read the multitude of blog posts and news articles, or read through the text 
> transcripts of the talks after Apple posts those.
> 
> If you're developing for Apple platforms, you need to keep abreast of what's 
> happening on those platforms. That's just common sense. Tech moves fast, and 
> if you don't stay informed and stay educated, you'll be left behind.
> 
> —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/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 21, 2019, at 12:20 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> If someone can afford days/weeks to do watch WWDC sessions consistently
> every year it's great. That's not a luxury all of us can afford and it's
> ridiculous to think this should be a requirement.

All you need to watch are the keynote, and the "State Of The Union" talks the 
same day. That's maybe 3-4 hours. Or if you're really short on time you can 
read the multitude of blog posts and news articles, or read through the text 
transcripts of the talks after Apple posts those.

If you're developing for Apple platforms, you need to keep abreast of what's 
happening on those platforms. That's just common sense. Tech moves fast, and if 
you don't stay informed and stay educated, you'll be left behind.

—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: Future of Cocoa

[Richard Charles via Cocoa-dev]

> On Nov 20, 2019, at 3:16 PM, Jean-Daniel  wrote:
> 
> If Obj-C is dead, why is Apple still adding new language extensions (and not 
> minor one) ?
> 
> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
> 


This commit on GitHub was made on Nov 18, 2019 by

Pierre Habouzit
Senior Software Engineer at Apple

and

Duncan Exon Smith
Engineering Manager, Clang Frontend Team at Apple

So that is a great point. If Objective-C is dying why is Apple going to all the 
trouble of adding new language extensions for performance gains?


--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: Future of Cocoa

[Pier Bover via Cocoa-dev]

I won't respond each of you one by one but here are a couple of
observations.

Metal is not a cross platform technology hence why so many projects still
rely on OpenGL in macOS (eg: Firefox).

I don't understand those "the writing was in the wall" type of comments.
Even if you think something was obvious all along the indisputable truth is
we only have guesses and rumors. It's mind blowing that anyone making
business decisions would be ok with this uncertainty.

If someone can afford days/weeks to do watch WWDC sessions consistently
every year it's great. That's not a luxury all of us can afford and it's
ridiculous to think this should be a requirement.

Some will argue "just jump on SwiftUI". Well a) SwiftUI is not mature and
b) best case scenario it will take 2-3 years before it has support for more
than 60-70% of macOS users. In certain industries (such as audio) the
majority of users will not update past Mojave for many years because that
would imply letting go of expensive hardware.

Anyway, I won't be annoying you anymore with what I believe are valid
concerns. It's time for me to leave this mailing list.

I wish you all the best.
___

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 5:21 PM, Saagar Jha  wrote:
> 
> Oh, I guess I didn’t explain what I was talking about well. I’m saying that 
> the compiler would do a full method inline but put it behind a check to see 
> if it’s legal to continue executing. 

That optimization would increase code size (it can't possibly decrease it.) And 
it can't do very effective inlining, because the code to be inlined is only 
conditionally executed, so it can't really be merged into the call site. All 
you really save is the time difference between `bar_is_unswizzled` and 
`objc_msgsend`, which probably isn't very much (although you do have better 
locality of reference.)

But I am not a compiler engineer, so this is just my hobbyist opinion :)

—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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

Oh, I guess I didn’t explain what I was talking about well. I’m saying that the 
compiler would do a full method inline but put it behind a check to see if it’s 
legal to continue executing. For example, code like this:

@interface Foo
- (void)bar;
@end

// Another method in some random class
- (void)baz {
Foo *foo = // whatever
[foo bar];
}

would end up being compiled to something like this:

- (void)baz {
Foo *foo = // whatever
if (bar_is_unswizzled()) {
// Inlined version of -[Foo bar]
} else {
// Fall back to going through objc_msgSend
}
}

where bar_is_unswizzled() is some sort of runtime check that makes sure that 
the actual target is what we had thought it’d be at compile time. I’d hope that 
a branch predictor would be able to do a pretty good job on this considering 
that the guessing “true” would work 99% of the time.

Saagar Jha

> On Nov 20, 2019, at 17:01, Jens Alfke  wrote:
> 
> 
> 
>> On Nov 20, 2019, at 2:46 PM, Saagar Jha > > wrote:
>> 
>> I am curious why this optimization went in instead of guarded speculative 
>> inlining, which would let you keep dynamism. 
> 
> If I understand it correctly, that only 'inlines' (really caches) the 
> resolved method address for the call site. That's not much of a win in Obj-C 
> where method lookup is already quite fast.
> 
> The real win comes with literally inlining the method at compile time. 
> Link-Time Optimization allows _any_ method anywhere in the program to be 
> inlined, provided the call is monomorphic. And this new feature allows 
> monomorphic method calls in Obj-C. This is a big win for small method like 
> getters/setters, and for methods with only one call site (i.e. where you 
> factor out a method for readability even though it's only used in one place.)
> 
> —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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:46 PM, Saagar Jha  wrote:
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. 

If I understand it correctly, that only 'inlines' (really caches) the resolved 
method address for the call site. That's not much of a win in Obj-C where 
method lookup is already quite fast.

The real win comes with literally inlining the method at compile time. 
Link-Time Optimization allows _any_ method anywhere in the program to be 
inlined, provided the call is monomorphic. And this new feature allows 
monomorphic method calls in Obj-C. This is a big win for small method like 
getters/setters, and for methods with only one call site (i.e. where you factor 
out a method for readability even though it's only used in one place.)

—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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

Probably because the benefit is minor compare to this optimisation (which let 
the compiler completely inline the called ‘method’ if it want).

The actual method dispatch implementation is fast enough (in case of cache hit) 
to not gain much from inline caching, which introduce another layer of caching 
with its cost.
It may even slow done the software as it add some additional checks to any 
method calls.



> Le 20 nov. 2019 à 23:46, Saagar Jha via Cocoa-dev  
> a écrit :
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. Maybe that was too complicated 
> to implement or didn’t have the right performance characteristics. But I 
> guess this isn’t really the right list for discussing that…
> 
> Saagar Jha
> 
>> On Nov 20, 2019, at 14:27, Jens Alfke via Cocoa-dev 
>>  wrote:
>> 
>> 
>> 
>>> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>>>  wrote:
>>> 
>>> If Obj-C is dead, why is Apple still adding new language extensions (and 
>>> not minor one) ?
>>> 
>>> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>>>  
>>> 
>> 
>> Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
>> optimization of internal methods — not just because the call is faster, but 
>> because the method body is now inlineable.
>> 
>> I remember talk of this inside Apple way back when (early 2000s) but at the 
>> time IIRC it was considered too dangerous to be worth the performance gain. 
>> These days it's probably even more of a win because of LTO.
>> 
>> —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/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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

I am curious why this optimization went in instead of guarded speculative 
inlining, which would let you keep dynamism. Maybe that was too complicated to 
implement or didn’t have the right performance characteristics. But I guess 
this isn’t really the right list for discussing that…

Saagar Jha

> On Nov 20, 2019, at 14:27, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>>  wrote:
>> 
>> If Obj-C is dead, why is Apple still adding new language extensions (and not 
>> minor one) ?
>> 
>> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>>  
>> 
> 
> Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
> optimization of internal methods — not just because the call is faster, but 
> because the method body is now inlineable.
> 
> I remember talk of this inside Apple way back when (early 2000s) but at the 
> time IIRC it was considered too dangerous to be worth the performance gain. 
> These days it's probably even more of a win because of LTO.
> 
> —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/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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>  wrote:
> 
> If Obj-C is dead, why is Apple still adding new language extensions (and not 
> minor one) ?
> 
> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>  
> 

Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
optimization of internal methods — not just because the call is faster, but 
because the method body is now inlineable.

I remember talk of this inside Apple way back when (early 2000s) but at the 
time IIRC it was considered too dangerous to be worth the performance gain. 
These days it's probably even more of a win because of LTO.

—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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 20 nov. 2019 à 01:26, Gerald Henriksen via Cocoa-dev 
>  a écrit :
> 
> On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:
> 
>> When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES 
>> to Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>> (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>> layer written in Objective-C), Swift and lots of other stuff. From my point 
>> of view I do not see Apple sweeping away Objective-C and the Cocoa 
>> frameworks any time soon. 
> 
> Just because Apple may need to keep Objective-C around for the
> frameworks doesn't mean they will continue to allow applications to be
> written in it.
> 
> All they need to do is either eliminate the option (stop shipping the
> Objective-C compiler), or do so by requiring all applications to have
> something that is only available via Swift.

If Obj-C is dead, why is Apple still adding new language extensions (and not 
minor one) ?

https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
 




___

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 8:28 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> For example the vast majority of audio software
> companies are still communicating to its users to not update to Catalina.
> Huge audio companies like Native Instruments are still struggling with this.

That's misleading. Native Instruments software all runs 64-bit, as far as I'm 
aware. The issue is that a 64-bit process cannot load 32-bit plugins 
(obviously), nor communicate with a 32-bit userspace hardware driver … and many 
of NI's customers have older 3rd party VST or AU plugins or drivers that would 
stop working.

NI has previously told their customers* they can work around this by launching 
their apps in 32-bit mode, but of course that no longer works in Catalina. 
That's what the warning is about.

(There's also the fact that many major OS upgrades have changes to Core Audio 
that can cause issues with audio apps, so there always seems to be a shake-out 
period where Apple and/or the audio developer release some maintenance fixes.)

—Jens

* 
https://support.native-instruments.com/hc/en-us/articles/209592169-Managing-Applications-and-Plug-ins-on-OS-X-32-64-bit-Systems
___

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: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

> On Nov 20, 2019, at 9:28 AM, Pier Bover  wrote:
> 
> > Its not Apples fault if you were not aware.  They were both highly talked 
> > about during their respective WWDC events.
> 
> The vast majority of developers do not go to the WWDC and do not have time to 
> watch the dozens (hundreds?) of hours of videos to maybe find something 
> relevant about the future of macOS dev. If that's how Apple communicates 
> their future plans then Apple has a communication problem.
32 bit being deprecated & it being killed were both announced during 
their respective WWDC keynote, if memory services, to a lot of fan fair.  If 
you only watch one WWDC video a year the keynote is the one to watch.  Its 
where most big future plans are announced.  There were also a bunch of WWDC 
sessions/videos and developer pages on how to move your products away from 32 
Bit too.  It was also covered on a bunch of Apple Developer web pages.  If you 
search around you can still find them.  It was also highly talked about on this 
and other mailing lists and forums as well as many mac news sites etc.  The 
information was there in many locations, you just had to pay attention.  Again, 
its not Apple’s fault if you were not aware.


> Companies like Adobe, Microsoft, etc, announce their plans publicly years in 
> advance. They have dedicates pages, blog posts, social media announcements 
> with dates of when these EOL changes will happen. For example Adobe announced 
> in 2017 it would kill the Flash Player by 2020.
Adobe only have you 3 years to move away from Flash Player.  Apple gave 
you 7 to move away from 32 Bit, yet you still complain?


> Personally I didn't know about 32 bits EOL until I heard about it with Mojave 
> user alerts, less than 2 years before Catalina was released. It didn't impact 
> me, but it did impact many companies that are still struggling with it. For 
> example the vast majority of audio software companies are still communicating 
> to its users to not update to Catalina. Huge audio companies like Native 
> Instruments are still struggling with this.
They had 7 years to get things in order.  I have sympathy for their 
users, but not for the company.  They either have mac developers with their 
heads in the sand, or they made a conscious business decision not to put 
resources towards moving away from 32 Bit.  In either case, again, its not 
Apple’s fault.


> Do you know for certain when Apple will stop shipping OpenGL with macOS? 
> Probably not. Most likely it will be announced less than a year before it 
> happens.
No I don’t know when OpenGL is being killed.  But Apple announced it is 
being deprecated which is your first, and very large, clue to start moving away 
from OpenGL in your products sooner rather than later.  Again, you have been 
told its going away, and historically it takes a few years for Apple to kill 
things like that.  If your products still use OpenGL by the time OpenGL is 
killed in a few years then it is totally on you, not Apple.  Just sayin’...

—Rob


___

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: Future of Cocoa

[Gary L. Wade via Cocoa-dev]

> On Nov 20, 2019, at 8:29 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> The vast majority of developers do not go to the WWDC and do not have time
> to watch the dozens (hundreds?) of hours of videos to maybe find something
> relevant about the future of macOS dev.

In that case, scan through the online transcripts, which are searchable, and 
the keynotes of the presentations.

Really, no one has any excuse. Either use what’s available and submit feedback 
when something isn’t clear or quit developing software.
--
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 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: Future of Cocoa

[Pier Bover via Cocoa-dev]

> Its not Apples fault if you were not aware.  They were both highly talked
about during their respective WWDC events.

The vast majority of developers do not go to the WWDC and do not have time
to watch the dozens (hundreds?) of hours of videos to maybe find something
relevant about the future of macOS dev. If that's how Apple communicates
their future plans then Apple has a communication problem.

Companies like Adobe, Microsoft, etc, announce their plans publicly years
in advance. They have dedicates pages, blog posts, social media
announcements with dates of when these EOL changes will happen. For example
Adobe announced in 2017 it would kill the Flash Player by 2020.

Personally I didn't know about 32 bits EOL until I heard about it with
Mojave user alerts, less than 2 years before Catalina was released. It
didn't impact me, but it did impact many companies that are still
struggling with it. For example the vast majority of audio software
companies are still communicating to its users to not update to Catalina.
Huge audio companies like Native Instruments are still struggling with this.

https://support.native-instruments.com/hc/en-us/articles/360001890378-macOS-10-15-Catalina-Compatibility-with-Native-Instruments-Products

Do you know for certain when Apple will stop shipping OpenGL with macOS?
Probably not. Most likely it will be announced less than a year before it
happens.
___

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: Future of Cocoa

[Ross Tulloch via Cocoa-dev]

> Nothing explicit is said about it, but none of the public-facing pages
> mention either Cocoa or Objective-C.  It's all SwiftUI and Swift. Searches
> still show pages for them, but not the clickable links I followed.

Try:

developer.apple.com -> Click “Develop” -> Click “Documentation” (both at the 
top of the page).

All the documentation for Cocoa is right there: AppKit, Foundation, etc, etc, 
etc, etc.
You can switch between Objective-C or Swift in the popup at the top of the page.


Ross.

___

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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

Saagar Jha

> On Nov 19, 2019, at 20:01, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Nov 19, 2019, at 6:24 PM, Pier Bover via Cocoa-dev 
>>  wrote:
>> 
>>> When/if Apple decides to deprecate Cocoa they will announce it many years 
>>> ahead of time
>>> 
>> 
>> Like they did with 32 bits and OpenGL deprecation?
>> 
> 
> 
> The 32 bit depreciation has had a lot of discussion on this thread.
> 
> Although depreciated OpenGL and related dynamic libraries are still present 
> in system frameworks on macOS Catalina. I have an app that depends on OpenGL 
> and GLU and it runs fine on Catalina.
> 
> OpenGL was release 27 years ago and is used extensively in many technical 
> fields. Perhaps this is why Apple has not yet removed these libraries from 
> the system and GPU vendors still support the OpenGL compatibility profile.

There are also a number of system applications that depend on it, so the 
framework will presumably stick around for a little while (though possibly be 
stripped of its headers and moved into the PrivateFrameworks folder at some 
point…)

> --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/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: Future of Cocoa

[Richard Charles via Cocoa-dev]

> On Nov 19, 2019, at 6:24 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
>> When/if Apple decides to deprecate Cocoa they will announce it many years 
>> ahead of time
>> 
> 
> Like they did with 32 bits and OpenGL deprecation?
> 


The 32 bit depreciation has had a lot of discussion on this thread.

Although depreciated OpenGL and related dynamic libraries are still present in 
system frameworks on macOS Catalina. I have an app that depends on OpenGL and 
GLU and it runs fine on Catalina.

OpenGL was release 27 years ago and is used extensively in many technical 
fields. Perhaps this is why Apple has not yet removed these libraries from the 
system and GPU vendors still support the OpenGL compatibility profile.

--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: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

> On Nov 19, 2019, at 6:24 PM, Pier Bover  wrote:
> 
> > When/if Apple decides to deprecate Cocoa they will announce it many years 
> > ahead of time 
> 
> Like they did with 32 bits and OpenGL deprecation?
Yes, exactly.  32Bit was deprecated in 2012 and officially killed in 
2019.  OpenGL was deprecated in 2018 and has not been killed yet.  Its not 
Apples fault if you were not aware.  They were both highly talked about during 
their respective WWDC events.

—Rob


___

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: Future of Cocoa

[Pier Bover via Cocoa-dev]

> When/if Apple decides to deprecate Cocoa they will announce it many years
ahead of time

Like they did with 32 bits and OpenGL deprecation?
___

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: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

The sky is not falling.  When/if Apple decides to deprecate Cocoa they will 
announce it many years ahead of time, like they did for Carbon back in 2012 
(which was only officially killed in 2019).  They typically make announcements 
like that at a WWDC.  They aren’t going to stop supporting it and stop letting 
apps built with it from launching out of the blue.  That would be a PR 
nightmare.  So everyone please take a breath.

—Rob


> On Nov 19, 2019, at 5:26 PM, Gerald Henriksen via Cocoa-dev 
>  wrote:
> 
> On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:
> 
>> When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES 
>> to Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>> (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>> layer written in Objective-C), Swift and lots of other stuff. From my point 
>> of view I do not see Apple sweeping away Objective-C and the Cocoa 
>> frameworks any time soon. 
> 
> Just because Apple may need to keep Objective-C around for the
> frameworks doesn't mean they will continue to allow applications to be
> written in it.
> 
> All they need to do is either eliminate the option (stop shipping the
> Objective-C compiler), or do so by requiring all applications to have
> something that is only available via 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/petrock%40mac.com
> 
> This email sent to petr...@mac.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: Future of Cocoa

[Gary L. Wade via Cocoa-dev]

There seems to be a misunderstanding that just because the word “Cocoa” doesn’t 
appear, nor "Objective-C” in the latest WWDC videos to a great extent, that 
they are no longer relevant.  If you watch any of the videos to the end, you’ll 
notice that rather than repeating every detail every year, the sessions instead 
reference previous years’ videos.  Since previous WWDC conferences have covered 
a lot more Objective-C and core Cocoa frameworks and they’re all available and 
free, why would anyone spend time repeating things when there’s plenty of new 
things to discuss?  An enterprising user would go back and watch the previous 
years’ sessions if they need that information.

By the way, the WWDC app on iOS, tvOS, and watchOS has been updated to be the 
Apple Developer App.

Introducing the Apple Developer App 

View on the App Store 

--
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 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: Future of Cocoa

[Gerald Henriksen via Cocoa-dev]

On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:

>When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES to 
>Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>(Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>layer written in Objective-C), Swift and lots of other stuff. From my point of 
>view I do not see Apple sweeping away Objective-C and the Cocoa frameworks any 
>time soon. 

Just because Apple may need to keep Objective-C around for the
frameworks doesn't mean they will continue to allow applications to be
written in it.

All they need to do is either eliminate the option (stop shipping the
Objective-C compiler), or do so by requiring all applications to have
something that is only available via 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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 19, 2019, at 12:51 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> If I understand it correctly, there is a linkage between Swift and 
> Objective-C. Apple devised a way to call the Cocoa frameworks written in 
> Objective-C from the Swift language using the magic of the LLVM compiler.

The Swift compiler and runtime know how the Objective-C runtime works, so so 
Swift can treat Obj-C classes and objects as first-class citizens.

> A great question would be is possible for Apple to pull the Objective-C rug 
> out from underneath the Cocoa frameworks leaving only a Swift implementation?

Sure, since you can create Obj-C compatible classes in Swift simply by using 
the @objc annotation.

However, rewriting a framework from scratch is always a perilous activity and 
not something to be done lightly. This may happen over time, but I wouldn't 
expect wholesale rewrites in the near future.

—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: Future of Cocoa

[Richard Charles via Cocoa-dev]

> On Nov 19, 2019, at 9:41 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> I have been poking around on developer.apple.com, trying to get the big
> picture on the future of Cocoa for Mac. Ditto for the future of big apps.
> 


Send an email to Aaron Hillegass. He might be able to give you an educated 
guess about the remaining life of the Cocoa frameworks in Objective-C and the 
future of big apps on the Mac. Let us know if you hear back from him and what 
he tells you.

https://academy.realm.io/posts/altconf-aaron-hillegass-eulogy-for-objective-c/

You could submit a developer technical support incident to Apple and ask them 
point blank how much longer they will be supporting the Cocoa frameworks in 
Objective-C. Let us know if you hear back from them assuming the answer is not 
under a non-disclosure agreement.


> 
> It's all SwiftUI and Swift.
> 


If I understand it correctly, there is a linkage between Swift and Objective-C. 
Apple devised a way to call the Cocoa frameworks written in Objective-C from 
the Swift language using the magic of the LLVM compiler. A great question would 
be is possible for Apple to pull the Objective-C rug out from underneath the 
Cocoa frameworks leaving only a Swift implementation?

Carbon was a completely different animal. Apple pulled, so to speak, the core 
out of Foundation and came up with Core Foundation to give life and 
interoperability for the Carbon layer. However NOTHING of lasting value was 
built on the Carbon layer. The whole Carbon thing can be swept away and what 
difference does it make.

When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES to 
Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
(Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
layer written in Objective-C), Swift and lots of other stuff. From my point of 
view I do not see Apple sweeping away Objective-C and the Cocoa frameworks any 
time soon. Essentially they said as much in their 64-Bit Transition Guide.

https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/HighLevelAPIs/HighLevelAPIs.html

--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: Future of Cocoa

[Tim McGaughy via Cocoa-dev]

This. So much this.

On 11/19/19, Steve Mills via Cocoa-dev  wrote:
> You should use an external poll site for this rather than filling the list
> with yet another thread full of discussions and arguments.
>
> Steve via iPhone
>
>> On Nov 19, 2019, at 10:42, Turtle Creek Software via Cocoa-dev
>>  wrote:
>>
>> Before I email comments to Apple, it would help to know more about how
>> other developers use Cocoa. Is it OK to run an informal poll?  I'll
>> consolidate it into a spreadsheet, and won't share any details without
>> consent.  Email me direct if you want more privacy.
>>
>
> ___
>
> 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/tmcgaughy%40gmail.com
>
> This email sent to tmcgau...@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: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

+1

Also, the reference docs can be toggled between Obj-C & Swift via the 
“Language” popup at the top of the page.

—Rob


> On Nov 19, 2019, at 9:48 AM, Steve Mills via Cocoa-dev 
>  wrote:
> 
> You should use an external poll site for this rather than filling the list 
> with yet another thread full of discussions and arguments.
> 
> Steve via iPhone
> 
>> On Nov 19, 2019, at 10:42, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Before I email comments to Apple, it would help to know more about how
>> other developers use Cocoa. Is it OK to run an informal poll?  I'll
>> consolidate it into a spreadsheet, and won't share any details without
>> consent.  Email me direct if you want more privacy.
>> 
> 
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@mac.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: Future of Cocoa

[Steve Mills via Cocoa-dev]

You should use an external poll site for this rather than filling the list with 
yet another thread full of discussions and arguments.

Steve via iPhone

> On Nov 19, 2019, at 10:42, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Before I email comments to Apple, it would help to know more about how
> other developers use Cocoa. Is it OK to run an informal poll?  I'll
> consolidate it into a spreadsheet, and won't share any details without
> consent.  Email me direct if you want more privacy.
> 

___

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