iOS/Mac app Entitlements.plist

About Entitlements

Entitlements confer specific capabilities or security permissions to your iOS or OS X app.

At a Glance

Set entitlement values in order to enable iCloud, push notifications, and App Sandbox. Each entitlement has a default value, which in most cases disables the capability associated with the entitlement. When you set an entitlement, you are overriding the default by providing an appropriate key-value pair.

  • iCloud entitlements let you enable the use of iCloud data storage for your iOS or OS X app.

    You set iCloud entitlement values on a target-by-target basis in your Xcode project.

  • Push notifications let your app alert the user even when your iOS or OS X app is not executing.

    You set push notification entitlement values as part of configuring your development and distribution provisioning profiles.

  • App Sandbox entitlements let you enable the security feature called sandboxing for your OS X app. (In iOS, all apps are sandboxed automatically, so these sandboxing entitlements do not apply.)

    By carefully enabling only the resource access that you need, you minimize the potential for damage if malicious code successfully exploits your app. You set App Sandbox entitlement values on a target-by-target basis in your Xcode project.

You can set many entitlements using the Summary tab of the Xcode target editor. Other entitlements require editing a target’s entitlements property listfile. Finally, a few entitlements are inherited from the iOS provisioning profile used to run the app.

The sort of value to associate with an entitlement key depends on the key. Many entitlement keys take Boolean values. For entitlements defined in a property list in an Xcode project, a Boolean entitlement value is either <true/> or <false/>. Some entitlement keys take a string or an array of strings as a value. Refer to the chapters in this document for specifics on the values to apply to the various entitlement keys.

To use any entitlement keys, you must code sign your app because an app’s entitlements are built in to its code signature.

 

https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AboutEntitlements.html

Coroutines in Lua

Paper:

 

Coroutines in Lua

Ana Lucia ´ de Moura , Noemi Rodriguez , Roberto Ierusalimschy
Departamento de Informatica ´ – PUC-Rio
Rua Marques de Sao˜ Vicente 225 – 22453-900 Rio de Janeiro, RJ

Abstract. After a period of oblivion, a renewal of interest in coroutines is being
observed. However, most current implementations of coroutine mechanisms are
restricted, and motivated by particular uses. The convenience of providing true
coroutines as a general control abstraction is disregarded. This paper presents
and discusses the coroutine facilities provided by the language Lua, a full implementation
of the concept of asymmetric coroutines. It also shows that this
powerful construct supports easy and succint implementations of useful control
behaviors.
1. Introduction
The concept of a coroutine is one of the oldest proposals for a general control abstraction.
It is attributed to Conway [Conway, 1963], who described coroutines as “subroutines who
act as the master program”, and implemented this construct to simplify the cooperation
between the lexical and syntactical analysers in a COBOL compiler. Marlin’s doctoral
thesis [Marlin, 1980], widely acknowledged as a reference for this mechanism, resumes
the fundamental characteristics of a coroutine as follows:

“the values of data local to a coroutine persist between successive calls”;

“the execution of a coroutine is suspended as control leaves it, only to carry on
where it left off when control re-enters the coroutine at some later stage”.
The aptness of the concept of a coroutine to express several useful control behaviors
was perceived and explored during some years in a number of contexts, such as
concurrent programming, simulation, text processing, artificial intelligence, and various
kinds of data structures manipulation [Marlin, 1980, Pauli and Soffa, 1980]. However, the
convenience of providing a programmer with this powerful control abstraction has been
disregarded by general-purpose language designers. with rare exceptions such as Simula
[Birtwistle et al., 1976], BCPL [Moody and Richards, 1980], Modula-2 [Wirth, 1985]
and Icon [Griswold and Griswold, 1996].
The absence of coroutine facilities in mainstream languages can be partly attributed
to the lacking of an uniform view of this concept, which was never precisely
defined. Moreover, most descriptions of coroutines found in the literature, Marlin’s thesis
included, are still based on Simula, a truly complex implementation of coroutines that
contributed to the common misconception that coroutines are an “awkward” construct,
difficult to manage and understand.
After a period of oblivion, we can now observe a renewal of interest in some
forms of coroutines, notably in two different groups. The first group corresponds to
developers of multitasking applications, who investigate the advantages of cooperative
task management as an alternative to multithreading environments [Adya et al., 2002,
Behren et al., 2003]. In this scenario, the concurrent constructs that support cooperative
multitasking are usually provided by libraries or system resources like Window’s fibers
[Richter, 1997]. It is worth noticing that, although the description of the concurrency
mechanisms employed in those works is no more than a description of the coroutine abstraction,
the term coroutine is not even mentioned.
Another currently observed resurgence of coroutines is in the context of scripting
languages, notably Lua, Python and Perl. Python [Schemenauer et al., 2001] has recently
incorporated a restricted form of coroutines that permits the development of simple iterators,
or generators, but are not powerful enough to implement interesting features that can
be written with true coroutines, including user-level multitasking. A similar mechanism
is being proposed for Perl [Conway, 2000]. A different approach was followed by the
designers of Lua, who decided on a full implementation of coroutines.
The purpose of this work is to present and discuss the coroutine facilities provided
by Lua. Section 2 gives a brief introduction to the language and describes its coroutine
facilities, providing an operational semantics for this mechanism. Section 3 illustrates the
expressive power of Lua asymmetric coroutines by showing some relevant examples of
their use. Section 4 discusses coroutines in some other languages. Section 5 presents our
conclusions.

http://www.inf.puc-rio.br/~roberto/docs/corosblp.pdf

XCode build a debugable ipa for generic devices

Do not need to connect the device to the computer

1. Command + B (using Debug configuration)

2. reveal the Product (xxx.app)

3. xcrun -sdk iphoneos PackageApplication xxx.app -o ~/Downloads/xxx.ipa

===========

Entitlement key: “get-task-allow” ,when signed into an application, allows other processes (like the debugger) to attach to your app. Distribution profiles require that this value be turned off, while development profiles require this value to be turned on (otherwise Xcode would never be able to launch and attach to your app).

<key>get-task-allow</key>
<true/>

see : http://stackoverflow.com/questions/1003066/what-does-get-task-allow-do-in-xcode

iOS Background Modes(background-fetch,remote-notification-fetch)

http://stackoverflow.com/questions/19068762/will-ios-launch-my-app-into-the-background-if-it-was-force-quit-by-the-user

 

 

Although this was not made clear by the WWDC video, a quick search on the developer forums turned this up:

https://devforums.apple.com/message/873265#873265 (login required)

Also keep in mind that if you kill your app from the app switcher (i.e. swiping up to kill the app) then the OS will never relaunch the app regardless of push notification or background fetch. In this case the user has to manually relaunch the app once and then from that point forward the background activities will be invoked. –pmarcos

That post was by an Apple employee so I think i can trust that this information is correct.

So it looks like when the app is killed from the app switcher (by swiping up), the app will never be launched, even for scheduled background fetches.


iOS 8 Update: The documentation has been clarified for iOS 8. The documentation can be readhere. Here is a relevant excerpt:

Use this method to process incoming remote notifications for your app. Unlike the application:didReceiveRemoteNotification: method, which is called only when your app is running in the foreground, the system calls this method when your app is running in the foreground or background. In addition, if you enabled the remote notifications background mode, the system launches your app (or wakes it from the suspended state) and puts it in the background state when a push notification arrives. However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.