Re: Documentation Workflow

[Richard Charles]

> On Dec 2, 2016, at 11:34 AM, Slipp Douglas Thompson 
>  wrote:
> 
> Alternatively, there's always archive.org's Wayback Machine.

> Since developer.apple.com's URL paths have changed quite a bit with the 
> recent narrow-body-giant-text-ification, I plugged 
> https://developer.apple.com/library/ios/navigation/ into the Wayback Machine 
> ( https://developer.apple.com/library/mac/navigation/ also works), chose a 
> capture date a couple years ago, and then used the “Documents [ ] 
> 4293 of 4293” search input to find the doc I was looking for.

It appears that October 21, 2014 was the last archive date for old style iOS 
documentation and content.

It appears that November 5, 2015 was the last archive date for old style mac 
documentation and content.

This would be a good starting point if you are looking for something older that 
is now gone.

--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: Message from iOS to watchOS

[J. Scott Tury]

Notifications for iOS will show on whatever device you are using currently.  If 
you’re not using one, it will show up on your watch.  If you’re using a iPad, 
it’ll show up on your iPad.  If you’r using your phone - it’ll show up there.  

There is no API that sends a Notification to a particular device per se.

I would just send a notification:  Local or remote.  The behavior should be 
essentially the same.  Send the title and message in the notification.  You can 
add in any actions you would like your user to be able to have.

Scott

> Date: Sat, 03 Dec 2016 13:48:31 +0700
> From: "Gerriet M. Denkmann" mailto:gerri...@icloud.com>>
> To: cocoa-dev mailto:cocoa-dev@lists.apple.com>>
> Subject: Message from iOS to watchOS
> Message-ID: <2001a5e8-10f8-4b30-86c4-9dfee6198...@icloud.com 
> >
> Content-Type: text/plain; charset=us-ascii
> 
> I have a pair of apps: iOS + watchOS.
> 
> The iOS app would like (e.g. when the user taps a button) to send some 
> (short) info to the watchOS app.
> The watchOS app probably should show something like a Notification Controller 
> Scene:
>   Message from iOS (title)
>   Something was done  (body)
>   Accept / Refuse (buttons)
> 
> I looked at UNUserNotificationCenter, but did not see any way to specify the 
> recipient of the notification.
> 
> And I am not interested in Push Notifications.  
> 
> Gerriet.
> 
> P.S. This is my first watch app, so I am more than usual clueless.
> 
___

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: Migrating shared library plugins to Cocoa Touch Frameworks

[Gary L. Wade]

Okay, enough with the F.U.D. which I already addressed. If you really want 
answers, go search the details yourself; they are there but maybe not as well 
found anymore, and some are mentioned in related WWDC talks. As for the new 
point, all dylibs must be part of an existing installation and code-signed; no 
downloadable plugins are allowed.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Dec 3, 2016, at 3:00 AM, Andreas Falkenhahn  wrote:
> 
>> On 03.12.2016 at 00:40 Jens Alfke wrote:
>> 
>> dlopen is hardly undocumented; it’s part of the core BSD Unix
>> library. It’s got a man page and everything.
> 
> That doesn't mean that it's ok to use it on iOS because of the sandbox.
> You aren't allowed to use other standard BSD functions like exit(),
> mkstemp(), exec(), system(), etc. on iOS either because of the sandbox.
> 
>> Prior to iOS 8, the sandbox that 3rd party iOS apps ran in blocked
>> calls to dlopen, as well as other attempts to load dynamic libraries
>> from within the app bundle. That is now no longer the case, so you
>> can use dlopen
> 
> Once again, that is your opinion unless there is any document from
> Apple explicitly stating that it's allowed. The fact that it works
> doesn't count :)
> 
> I don't want to sound overly pedantic here and I really believe you
> guys that probably it's really allowed to use dlopen() starting with
> iOS 8 and everything is fine. All I'm trying to stress here is that
> basically when using dlopen() we are relying on undocumented behaviour
> and there is no guarantee that what we're doing is really officially
> supported.
> 
>> That’s sort of weird; however, a framework is just a dynamic
>> library packaged with its headers in a specific bundle format. You
>> can always use a framework target and then add a script build step
>> to copy the library out of the framework.
> 
> Once again, that's relying on undocumented behaviour. It's obvious
> that a framework is just a bundle containing a dylib but nobody
> can say whether manually dlopen()ing this dylib is something that is
> allowed on iOS. Maybe future versions of iOS will block manual dlopen()
> access to the dylib inside the framework and will only allow the
> system dylib loader to open it. Who knows.
> 
>> I think the lack of a dylib target may just reflect that plug-ins
>> of the kind you’re implementing aren’t really very useful on iOS.
>> Since there’s no way to install extra plugins (downloading
>> executable code is explicitly forbidden), the set of plugins is
>> effectively fixed, meaning it would be more efficient to just
>> statically link them all into the app.
> 
> What about NSDocumentDirectory? Users could copy additional plugins
> as frameworks into the app's documents directory using iTunes. Will
> dlopen()ing such dylibs work as well? Or does it only work when the
> binaries are stored in the main bundle container?
> 
> -- 
> 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: Migrating shared library plugins to Cocoa Touch Frameworks

[Andreas Falkenhahn]

On 03.12.2016 at 00:40 Jens Alfke wrote:

> dlopen is hardly undocumented; it’s part of the core BSD Unix
> library. It’s got a man page and everything.

That doesn't mean that it's ok to use it on iOS because of the sandbox.
You aren't allowed to use other standard BSD functions like exit(),
mkstemp(), exec(), system(), etc. on iOS either because of the sandbox.

> Prior to iOS 8, the sandbox that 3rd party iOS apps ran in blocked
> calls to dlopen, as well as other attempts to load dynamic libraries
> from within the app bundle. That is now no longer the case, so you
> can use dlopen

Once again, that is your opinion unless there is any document from
Apple explicitly stating that it's allowed. The fact that it works
doesn't count :)

I don't want to sound overly pedantic here and I really believe you
guys that probably it's really allowed to use dlopen() starting with
iOS 8 and everything is fine. All I'm trying to stress here is that
basically when using dlopen() we are relying on undocumented behaviour
and there is no guarantee that what we're doing is really officially
supported.

> That’s sort of weird; however, a framework is just a dynamic
> library packaged with its headers in a specific bundle format. You
> can always use a framework target and then add a script build step
> to copy the library out of the framework.

Once again, that's relying on undocumented behaviour. It's obvious
that a framework is just a bundle containing a dylib but nobody
can say whether manually dlopen()ing this dylib is something that is
allowed on iOS. Maybe future versions of iOS will block manual dlopen()
access to the dylib inside the framework and will only allow the
system dylib loader to open it. Who knows.

> I think the lack of a dylib target may just reflect that plug-ins
> of the kind you’re implementing aren’t really very useful on iOS.
> Since there’s no way to install extra plugins (downloading
> executable code is explicitly forbidden), the set of plugins is
> effectively fixed, meaning it would be more efficient to just
> statically link them all into the app.

What about NSDocumentDirectory? Users could copy additional plugins
as frameworks into the app's documents directory using iTunes. Will
dlopen()ing such dylibs work as well? Or does it only work when the
binaries are stored in the main bundle container?

-- 
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