Privacy is paramount: it’s critical to be transparent about the privacy-related data and resources you require and essential to protect the data people allow you to access.
개인정보 보호는 매우 중요합니다: 개인정보 관련 데이터와 리소스에 대해 투명해야 하며, 사용자가 액세스 허용한 데이터를 보호하는 것이 필수입니다.
People use their devices in very personal ways and they expect apps to help them preserve their privacy.
사람들은 자신의 장치를 매우 개인적인 방식으로 사용하며, 앱이 그들의 개인 정보를 보호하는 데 도움이 될 것을 기대합니다.
역자 첨언
When you submit a new or updated app, you must provide details about your privacy practices and the privacy-relevant data you collect so the App Store can display the information on your product page. (You can manage this information at any time in App Store Connect.) People use the privacy details on your product page to make an informed decision before they download your app. To learn more, see App privacy details on the App Store.
새로운 앱이나 업데이트된 앱을 제출할 때, App Store에서 제품 페이지에 정보를 표시하기 위해 개인 정보 처리 방침과 수집하는 개인 정보와 관련된 세부 정보를 제공해야 합니다. (이 정보는 App Store Connect에서 언제든지 관리할 수 있습니다.) 사람들은 앱을 다운로드하기 전에 제품 페이지의 개인 정보 세부 정보를 참고하여 신중한 결정을 내립니다. 자세한 내용은 App Store의 앱 개인 정보 세부 정보를 참조하십시오.
→ 유저가 앱 스토어에 개인정보 처리 방침을 보고 앱의 사용 유무를 선택하기에, 관련 세부 정보를 제공하기
An app’s App Store product page helps people understand the app’s privacy practices before they download it.
앱의 App Store 제품 페이지는 사람들이 해당 앱을 다운로드하기 전에 개인 정보 처리 방침을 이해할 수 있도록 도와줍니다.
Request access only to data that you actually need. Asking for more data than a feature needs — or asking for data before a person shows interest in the feature — can make it hard for people to trust your app. Give people precise control over their data by making your permission requests as specific as possible.
실제로 필요한 데이터에만 액세스를 요청하세요. 기능이 필요한 데이터보다 더 많은 데이터를 요청하거나 사용자가 해당 기능에 관심을 표시하기 전에 데이터를 요청하는 것은 사용자가 앱을 신뢰하기 어렵게 만들 수 있습니다. 사용자의 데이터에 대한 정밀한 제어를 제공하기 위해 권한 요청을 가능한 한 구체적으로 만들어 사용자에게 제어권을 부여하세요.
→ 실제로 데이터가 필요할 때, 권한 요청을 구체적으로 하여 신뢰성을 높이기
Be transparent about how your app collects and uses people’s data. People are less likely to be comfortable sharing data with your app if they don’t understand exactly how you plan to use it. Always respect people’s choices to use system features like Hide My Email and Mail Privacy Protection, and be sure you understand your obligations with regard to app tracking. To learn more about Apple privacy features, see Privacy; for developer guidance, see User privacy and data use.
앱이 데이터를 수집하고 사용하는 방식에 대해 투명해야 합니다. 사용자는 앱이 데이터를 어떻게 수집하고 사용할 계획인지 정확히 이해하지 못하면 앱과 데이터를 공유하는 데 불편해질 수 있습니다. 항상 Hide My Email 및 Mail Privacy Protection과 같은 시스템 기능을 사용하는 사용자의 선택을 존중하고 앱 추적에 관한 권한을 이해하는 것이 중요합니다. Apple의 개인 정보 보호 기능에 대한 자세한 내용은 Privacy를 참조하고, 개발자 가이드는 User privacy and data use를 참조하세요.
→ 데이터를 수집하고 사용하는 것에 대한 이해를 충분히 시켜주고 사용자의 옵션 선택을 존중하기
Process data on the device where possible. In iOS, for example, you can take advantage of the Apple Neural Engine and custom CreateML models to process the data right on the device, helping you avoid lengthy and potentially risky round trips to a remote server.
가능한 경우 기기에서 데이터를 처리하세요. 예를 들어 iOS에서는 Apple Neural Engine 및 사용자 정의 CreateML 모델을 활용하여 데이터를 기기에서 직접 처리할 수 있으며, 이렇게 하면 원격 서버로의 긴 시간이 걸리고 잠재적으로 위험한 왕복을 피할 수 있습니다.
→ 가능만 하다면, 서버를 거치지 말고 자체 기기에서 개인 정보를 활용해 서비스를 제공하기
역자 첨언
Adopt system-defined privacy protections and follow security best practices. For example, in iOS 15 and later, you can rely on CloudKit to provide encryption and key management for additional data types, like strings, numbers, and dates.
시스템에서 정의한 개인 정보 보호 기능을 채택하고 보안 모범 사례를 따르세요. 예를 들어 iOS 15 이상에서는 CloudKit을 신뢰하여 문자열, 숫자 및 날짜와 같은 추가 데이터 유형에 대한 암호화 및 키 관리를 제공하므로 보안을 강화할 수 있습니다.
→ 시스템에서 제공하는 개인 정보 보호 기능을 활용하기
Here are several examples of the things you must request permission to access:
다음은 액세스 권한을 요청해야 하는 몇 가지 예시입니다:
•
Personal data, including location, health, financial, contact, and other personally identifying information
•
블루투스 주변 장치, 홈 자동화 기능, Wi-Fi 연결 및 로컬 네트워크와 같은 보호된 리소스
•
User-generated content like emails, messages, calendar data, contacts, gameplay information, Apple Music activity, HomeKit data, and audio, video, and photo content
•
이메일, 메시지, 캘린더 데이터, 연락처, 게임 플레이 정보, Apple Music 활동, HomeKit 데이터, 오디오, 비디오 및 사진 콘텐츠와 같은 사용자가 생성한 콘텐츠
•
Protected resources like Bluetooth peripherals, home automation features, Wi-Fi connections, and local networks
•
위치, 건강, 금융, 연락처 및 기타 개인 식별 정보를 포함한 개인 데이터
•
Device capabilities like camera and microphone
•
카메라와 마이크와 같은 장치 기능
•
In a visionOS app running in a Full Space, ARKit data, such as hand tracking, plane estimation, image anchoring, and world tracking
•
"Full Space"에서 실행되는 visionOS 앱에서는 ARKit 데이터, 예를 들면 손 추적, 평면 추정, 이미지 기반 앵커링, 그리고 월드 트래킹과 같은 ARKit 데이터.
•
The device’s advertising identifier, which supports app tracking
•
앱 추적을 지원하는 장치의 광고 식별자
The system provides a standard alert that lets people view each request you make. You supply copy that describes why your app needs access, and the system displays your description in the alert. People can also view the description — and update their choice — in Settings > Privacy.
시스템은 사람들이 각각의 요청을 볼 수 있는 표준 경고창을 제공합니다. 앱이 access를 필요로 하는 이유를 설명하는 문구를 제공하고, 시스템은 해당 설명을 경고창에 표시합니다. 사람들은 설정 > 개인 정보에서 해당 설명을 볼 수 있으며, 선택을 업데이트할 수도 있습니다.
→ 앱이 위와 같은 access를 할 때, 이유를 경고창에 표시해야 합니다. 유저가 경고에 대한 선택을 이후에 설정에서 변경 가능
역자 참고
Request permission only when your app clearly needs access to the data or resource. It’s natural for people to be suspicious of a request for personal information or access to a device capability, especially if there’s no obvious need for it. Ideally, wait to request permission until people actually use an app feature that requires access. For example, you can use the location button to give people a way to share their location after they indicate interest in a feature that needs that information.
데이터 또는 리소스에 명확히 액세스해야만 하는 경우에만 권한을 요청하세요. 개인 정보나 장치 기능에 대한 요청은 명확한 필요성이 없는 경우 사람들이 의심할 수 있습니다. 가능하면 액세스를 필요로 하는 앱 기능을 실제로 사용하는 시점까지 권한 요청을 미루는 것이 이상적입니다. 예를 들어, 사용자가 해당 정보가 필요한 기능에 관심을 표시한 후에 위치를 공유할 수 있는 location button을 사용할 수 있습니다.
→ 앱의 기능을 유저가 사용하기 위해 access가 꼭 필요로 하며 그 시점이 되었을 때, 권한을 요청하기
Avoid requesting permission at launch unless the data or resource is required for your app to function. People are less likely to be bothered by a launch-time request when it’s obvious why you’re making it. For example, people understand that a navigation app needs access to their location before they can benefit from it. Similarly, before people can play a visionOS game that lets them bounce virtual objects off walls in their surroundings, they need to permit the game to access information about their surroundings.
앱이 작동하는 데 필요한 경우가 아니라면, 시작 시 권한을 요청하지 마세요. 앱이 왜 권한을 요청하는지 명확하게 이해할 수 있는 경우, 시작 시 권한 요청이 사람들을 귀찮게 할 가능성이 적습니다. 예를 들어, 사람들은 위치에 액세스할 수 있어야만 이용할 수 있다는 점에서 네비게이션 앱이 위치 권한에 접근해야 한다는 것을 이해합니다. 마찬가지로, 사용자들이 주변의 벽을 이용하여 가상 객체를 튀기게 하는 visionOS 게임을 플레이하기 전에, 그들은 게임이 주변 환경에 대한 정보에 접근하는 것을 허용해야 합니다.
→ 앱 시작 시, 바로 access가 필요한 경우가 아니라면 권한을 요청하지 말기
Write copy that clearly describes how your app uses the ability, data, or resource you’re requesting. The standard alert displays your copy (called a purpose string or usage description string) after your app name and before the buttons people use to grant or deny their permission. Aim for a brief, complete sentence that’s straightforward, specific, and easy to understand. Use sentence case, avoid passive voice, and include a period at the end. For developer guidance, see Requesting access to protected resources and App Tracking Transparency.
요청하는 ability, 데이터 또는 리소스를 명확히 설명하는 문구를 작성하세요. 표준 경고창은 앱 이름 바로 뒤에 그리고 권한 부여 또는 거부를 위한 버튼들 앞에 여러분의 문구(목적 문장 또는 사용 설명 문장이라고 함)를 표시합니다. 간결 하면서 완전한 문장을 목표로 하고, 단순하고 구체적이며 이해하기 쉬운 문구를 사용하세요. 문장 형식을 사용하고, 수동태를 피하고, 마침표를 넣으세요. 개발자 안내는 보호된 리소스에 대한 액세스 요청 및 앱 추적 투명성에서 확인할 수 있습니다.
→ 권한 요청을 위해 “단순함, 구체적인, 이해하기 쉬운, 문장 형식, 능동태, 마침표 사용”의 규칙을 지키기
역자 참고
Here are several examples of the standard system alert:
Ideally, the current context helps people understand why you’re requesting their permission. If it’s essential to provide additional details, you can display a custom screen before the system alert appears. The following guidelines apply to custom screens that display before system alerts that request permission to access protected data and resources, including camera, microphone, location, contact, calendar, and tracking.
이상적으로는 현재 맥락이 사용자에게 권한 요청의 이유를 이해시켜 줍니다. 추가적인 세부 정보를 제공해야 할 경우, 시스템 경고창이 나타나기 전에 커스텀 화면을 표시할 수 있습니다. 다음 지침은 카메라, 마이크, 위치, 연락처, 캘린더 및 추적과 관련된 보호된 데이터 및 리소스에 대한 시스템 경고 요청 이전에 표시되는 사용자 정의 화면에 적용됩니다.
→ 앱 사용 맥락으로 권한 요청이 이해가 애매할 경우, 시스템 경고창과 더불어 custom 화면을 사용할 수 있음
Include only one button and make it clear that it opens the system alert. People can feel manipulated when a custom screen also includes a button that doesn’t open the alert because the experience diverts them from making their choice. Another type of manipulation is using a term like “Allow” to title the custom screen’s button. If the screen’s button seems similar in meaning and visual weight to the allow button in the alert, people can be more likely to choose the alert’s allow button without meaning to. Use a term like “Continue” or “Next” to title your custom screen’s single button, clarifying that its action is to open the system alert.
버튼을 하나만 포함하고 해당 버튼이 시스템 경고창을 열 수 있도록 명확하게 해야 합니다. custom 화면에서 시스템 경고창을 열지 않는 버튼이 포함되어 있는 경우, 사용자는 선택을 내리는 것에서 분기되는 경험을 겪을 수 있습니다. 또 다른 조작 방식은 "허용"과 같은 용어를 사용하여 사용자 정의 화면의 버튼에 제목을 지정하는 것입니다. 화면의 버튼이 경고창의 "허용" 버튼과 의미와 시각적 가중치가 유사해 보이면, 사용자들은 그들의 의도와는 상관없이 경고창의 허용 버튼을 선택할 가능성이 높아질 수 있습니다. 사용자 정의 화면의 단일 버튼에 "계속"이나 "다음"과 같은 용어를 사용하여 제목을 붙여 시스템 경고창을 열도록 하는 것으로 화면의 버튼이 시스템 경고창을 열기 위한 동작임을 명확히 해야 합니다.
역자 참조
Don’t include additional actions in your custom screen. For example, don’t provide a way for people to leave the screen without viewing the system alert — like offering an option to close or cancel.
사용자 정의 화면에 추가 동작을 포함하지 마세요. 예를 들어, 시스템 경고를 볼 필요 없이 화면을 나가는 방법을 제공하지 마십시오. 즉, 닫기 또는 취소 옵션을 제공하는 것과 같은 것을 의미합니다.
App tracking is a sensitive issue. In some cases, it might make sense to display a custom screen that describes the benefits of tracking. If you want to perform app tracking as soon as people launch your app, you must display the system-provided alert before you collect any tracking data.
앱 추적은 민감한 문제입니다. 일부 경우에는 추적의 이점을 설명하는 custom 화면을 표시하는 것이 유용할 수 있습니다. 사용자가 앱을 시작할 때 바로 추적을 수행하려면, 추적 데이터를 수집하기 전에 시스템에서 제공하는 경고창을 표시해야 합니다.
→ Tracking 요청을 하기 전, 왜 tracking 해야 하는지 pre-alert 화면 만들기
Never precede the system-provided alert with a custom screen that could confuse or mislead people. People sometimes tap quickly to dismiss alerts without reading them. A custom messaging screen that takes advantage of such behaviors to influence choices will lead to rejection by App Store review.
시스템에서 제공하는 경고창 이전에 혼란을 야기하거나 오해를 불러 일으키는 커스텀 화면을 표시해서는 절대로 안 됩니다. 사람들은 때로 경고창을 읽지 않고 빠르게 탭하여 닫습니다. 이러한 동작을 이용하여 선택에 영향을 미쳐 이익을 얻으려는 커스텀 메시지 화면은 App Store 검토에서 거부 사유가 될 수 있습니다.
→ 사람들이 경고창을 잘 읽지 않고 버튼을 클릭하는 것을 이용하여, pre-alert 이외의 기능을 하기 위해 의도하지 말기
There are several prohibited custom-screen designs that will cause rejection. Some examples are offering incentives, displaying a screen or window that looks like a request, displaying an image of the alert, and annotating the screen behind the alert (as shown below). To learn more, see App Store Review Guidelines: 5.1.1 (iv).
거부 사유가 될 수 있는 몇 가지 금지된 사용자 정의 화면 디자인이 있습니다. 예를 들어 인센티브 제공, 요청처럼 보이는 화면 또는 window 표시, 경고창 이미지 표시, 경고창 뒷면에 주석 표시 등이 있습니다. 더 많이 알기 위해서, App Store 리뷰 가이드라인: 5.1.1 (iv)를 참조하십시오.
→ 하단을 참조하여 Tracking pre-alert 디자인 거부 사항을 확인하기
Incentive Imitation request
Don’t offer incentives for granting the request. You can’t offer people compensation for granting their permission, and you can’t withhold functionality or content or make your app unusable until people allow you to track them.
요청을 수락하는 대가로 인센티브를 제공하지 마십시오. 권한을 부여하는 대가로 보상을 제공하거나, 기능이나 콘텐츠를 제한하거나 앱을 사용할 수 없게 만들어서는 안 됩니다.
→ 권한 부여에 대한 대가로 인센티브 제공 또는 앱의 제한은 피하기
Don’t display a custom screen that mirrors the functionality of the system alert. In particular, don’t create a button title that uses “Allow” or similar terms, because people don’t allow anything in a pre-alert screen.
Alert image Alert annotation
Don’t show an image of the standard alert and modify it in any way.
Don’t draw a visual cue that draws people’s attention to the system alert’s Allow button.
In iOS, iPadOS, and watchOS, Core Location provides a button so people can grant your app temporary authorization to access their location at the moment a task needs it. A location button’s appearance can vary to match your app’s UI and it always communicates the action of location sharing in a way that’s instantly recognizable.
iOS, iPadOS 및 watchOS에서, Core Location은 작업이 필요한 시점에 앱에 일시적인 위치 액세스 권한을 부여하기 위한 버튼을 제공합니다. location 버튼은 앱의 UI와 일치하도록 디자인 할 수 있으며, 항상 즉시 알아볼 수 있는 방식으로 위치 공유 동작을 전달합니다.
→ 일시적으로 사용자 위치에 access 할 수 있는 버튼 존재
역자 첨언
The first time people open your app and tap a location button, the system displays a standard alert. The alert helps people understand how using the button limits your app’s access to their location, and reminds them of the location indicator that appears when sharing starts.
사람들이 앱을 처음 열고 위치 버튼을 탭할 때, 시스템은 표준 경고창을 표시합니다. 이 경고창은 위치 버튼을 사용하는 방법이 앱이 위치에 대한 액세스를 제한하는 방식을 이해하는 데 도움을 주며, 공유가 시작되면 표시되는 위치 표시기에 대한 알림을 제공합니다.
→ 해당 앱에서 사용자 위치에 대한 access를 처음 할 때, 표준 경고창을 표시하기
After people confirm their understanding of the button’s action, simply tapping the location button gives your app one-time permission to access their location. Although each one-time authorization expires when people stop using your app, they don’t need to reconfirm their understanding of the button’s behavior.
사람들이 버튼의 동작을 확인한 후에는 단순히 위치 버튼을 탭함으로써 앱이 위치에 대한 일회성 권한을 얻을 수 있습니다. 각각의 일회성 권한은 사람들이 앱을 사용하지 않을 때 만료되지만, 버튼의 동작에 대한 이해를 다시 확인할 필요는 없습니다.
→ 버튼을 통해 사용자 위치 access를 하여 사용해야하는 서비스를 단 한번 경험한다면, 그 다음은 다시 이해 시킬 필요가 없음
Note
If your app has no authorization status, tapping the location button has the same effect as when a person chooses Allow Once in the standard alert. If people previously chose While Using the App, tapping the location button doesn’t change your app’s status. For developer guidance, see LocationButton (SwiftUI) and CLLocationButton (Swift).
앱에 권한 상태가 없는 경우, 위치 버튼을 탭하는 것은 사람이 표준 경고창에서 Allow Once을 선택한 것과 동일한 효과가 있습니다. 사람들이 이전에 While Using the App을 선택한 경우, 위치 버튼을 탭해도 앱의 상태가 변경되지 않습니다. 개발자 가이드는 LocationButton(SwiftUI)와 CLLocationButton (Swift)을 참조하세요.
→ 앱에 access 권한이 없더라도, location 버튼을 누른다면 권한이 생깁니다. 표준 경고창에서 사용자가 어떤 권한을 선택하냐에 따라 access 권한 기간이 달라짐
역자 첨언
Consider using the location button to give people a lightweight way to share their location for specific app features. For example, your app might help people attach their location to a message or post, find a store, or identify a building, plant, or animal they’ve encountered in their location. If you know that people often grant your app Allow Once permission, consider using the location button to help them benefit from sharing their location without having to repeatedly interact with the alert.
특정 앱 기능을 위해 위치 버튼을 사용하여 사람들에게 가벼운 방식으로 위치 공유를 제공하는 것을 고려하세요. 예를 들어, 앱에서 사람들이 메시지나 게시물에 위치를 첨부하거나 가게를 찾거나, 그들의 위치에서 만난 건물, 식물 또는 동물을 식별하는 데 도움이 될 수 있습니다. 사람들이 앱에 Allow Once 권한을 부여하는 경우, 반복적으로 경고창과 상호 작용하지 않고도 위치 공유의 이점을 누릴 수 있도록 위치 버튼을 사용하는 것을 고려하세요.
→ 위치 정보를 활용한 다양한 서비스를 구상해보세요. + Allow Once 권한 선택시 location 버튼과 첫 상호작용 이후에 경고창을 사용하지 않는 것이 좋음
역자 첨언
Consider customizing the location button to harmonize with your UI. Specifically, you can:
사용자 인터페이스(UI)와 조화를 이루기 위해 location 버튼을 디자인 하는 것을 고려하세요. 구체적으로 다음을 할 수 있습니다:
→ 하단의 옵션들을 참고하여 location 버튼 디자인
•
Choose the system-provided title that works best with your feature, such as “Current Location” or “Share My Current Location.”
•
기능에 가장 적합한 시스템 제공 제목을 선택하세요. 예를 들어, "현재 위치" 또는 "내 현재 위치 공유"와 같은 제목을 선택할 수 있습니다.
•
Choose the filled or outlined location glyph.
•
채워진 또는 외곽선이 그려진 위치 그림을 선택하세요.
역자 첨언
•
Select a background color and a color for the title and glyph.
•
배경색과 제목 및 그림의 색상을 선택하세요.
•
Adjust the button’s corner radius.
•
버튼의 corner radius을 조정하세요.
To help people recognize and trust location buttons, you can’t customize the button’s other visual attributes. The system also ensures a location button remains legible by warning you about problems like low-contrast color combinations or too much translucency. In addition to fixing such problems, you’re responsible for making sure the text fits in the button — for example, button text needs to fit without truncation at all accessibility text sizes and when translated into other languages.
사람들이 위치 버튼을 인식하고 신뢰할 수 있도록하기 위해 당신이 버튼의 다른 시각적 속성을 정의할 수는 없습니다. 시스템은 또한 낮은 대비 색상 조합이나 너무 많은 투명도와 같은 문제에 대해 경고하여 위치 버튼이 가독성을 유지하도록 보장합니다. 이러한 문제를 수정하는 것 외에도, 버튼에 텍스트가 맞도록 해야합니다. 예를 들어, 버튼 텍스트는 모든 접근성 텍스트 크기와 다른 언어로 번역 되었을 때 잘리지 않고 맞아야합니다.
→ location 버튼 디자인을 돋보이게 또는 잘 보이지 않게 디자인 하지 않도록 하기
Important
If the system identifies consistent problems with your customized location button, it won’t give your app access to the device location when people tap it. Although such a button can perform other app-specific actions, people may lose trust in your app if your location button doesn’t work as they expect.
시스템이 사용자 정의된 위치 버튼에 일관된 문제를 식별하면, 사용자가 해당 버튼을 누를 때 장치 위치에 대한 액세스 권한을 앱에 부여하지 않을 수 있습니다. 또는 이러한 버튼은 다른 앱에서 작업을 수행할 수는 있을지도 모르지만, 위치 버튼이 사용자의 기대대로 작동하지 않으면 사용자들은 앱에 대한 신뢰를 잃을 수 있습니다.
→ location 버튼에 문제가 많다면, 시스템에서 강제적으로 access 권한을 막을 수도 있음
Protecting people’s information is paramount. Give people confidence in your app’s security and help preserve their privacy by taking advantage of system-provided security technologies when you need to store information locally, authorize people for specific operations, and transport information across a network.
사용자 정보의 보호는 매우 중요합니다. 사용자의 개인 정보를 안전하게 보호하고 개인 정보를 유지하기 위해, 로컬에 정보를 저장하거나 특정 작업에 대한 권한을 부여하거나 네트워크를 통해 정보를 전송해야 할 때, 시스템에서 제공하는 보안 기술을 활용하세요.
→ 로컬에 정보 저장하거나 네트워크를 통해 정보 전송을 할 때, 시스템에서 제공하는 보안 사용
Here are some high-level guidelines.
다음은 몇 가지 고수준 지침입니다.
Avoid relying solely on passwords for authentication. Where possible, use passkeys to replace passwords. If you need to continue using passwords for authentication, augment security by requiring two-factor authentication (for developer guidance, see Securing Logins with iCloud Keychain Verification Codes). To further protect access to apps that people keep logged in on their device, use biometric identification like Face ID, Optic ID, or Touch ID. For developer guidance, see Local Authentication.
비밀번호만을 사용한 인증에만 의존하지 않도록 하세요. 가능하면 비밀번호 대신 passkeys를 사용하세요. 인증에 계속해서 비밀번호를 사용해야 하는 경우, (개발자 지침에서 확인할 수 있는 것처럼 Securing Logins with iCloud Keychain Verification Codes) 두 단계 인증을 요구함으로써 보안을 강화하세요. 사용자가 기기에 로그인한 상태를 계속해서 보호하기 위해 얼굴 인식(Face ID), 광학 인식(Optic ID), 또는 손가락 인식(Touch ID)과 같은 생체 인식을 사용하세요. 개발자 안내서에서 확인할 수 있는 것처럼 로컬 인증(Local Authentication.)을 활용하세요.
→ 인증에 비밀번호에 추가적으로 지문 인증 등 다른 기술을 사용
Store sensitive information in a keychain. A keychain provides a secure, predictable user experience when handling someone’s private information. For developer guidance, see Keychain Services.
→ 키체인을 활용하여 민감한 정보 저장
역자 첨언
Never store passwords or other secure content in plain-text files. Even if you restrict access using file permissions, sensitive information is much safer in an encrypted keychain.
비밀번호나 기타 보안 내용을 일반 텍스트 파일에 저장하지 마세요. 파일 권한을 사용하여 액세스를 제한하더라도, 민감한 정보는 암호화된 키체인에 저장하는 것이 훨씬 안전합니다.
→ 보통의 text 파일에 비밀번호나 보안돼야 할 정보 저장하지 않기 → 키체인 활용
Avoid inventing custom authentication schemes. If your app requires authentication, prefer system-provided features like Sign in with Apple or Password AutoFill. For guidance, see Managing accounts.
커스텀 인증 체계를 개발하지 마세요. 앱이 인증을 필요로 하는 경우, Sign in with Apple 또는 Password AutoFill과 같은 시스템에서 제공하는 기능을 활용하세요. 관련된 지침은 계정 관리를 참조하세요.
→ 자체 제작 로그인을 지양하고, Apple Login 또는 Password AutoFill 등 시스템에서 제공하는 기능을 활용
역자 첨언
No additional considerations for iOS, iPadOS, tvOS, or watchOS.
Sign your app with a valid Developer ID. If you choose to distribute your app outside the store, signing your app with Developer ID identifies you as an Apple developer and confirms that your app is safe to use. For developer guidance, see Xcode Help.
유효한 개발자 ID로 앱을 서명하세요. 앱을 스토어 외부에서 배포하는 경우, 개발자 ID로 앱을 signing함으로써 Apple 개발자로 식별되고 앱이 안전하게 사용될 수 있음을 확인할 수 있습니다. 관련된 개발자 지침은 Xcode 도움말을 참조하세요.
→ 앱을 앱스토어 외부에서 배포하는 경우, 개발자 ID로 Signing 하기
Protect people’s data with app sandboxing. Sandboxing provides your app with access to system resources and user data while protecting it from malware. All apps submitted to the Mac App Store require sandboxing. For developer guidance, see Configuring the macOS App Sandbox.
앱 샌드박싱을 통해 사용자 데이터를 보호하세요. 샌드박싱은 앱이 시스템 리소스와 사용자 데이터에 접근할 수 있으면서도 악성 소프트웨어로부터 보호될 수 있도록 합니다. Mac App Store에 제출되는 모든 앱은 샌드박싱이 필요합니다. 관련된 개발자 지침은 macOS 앱 샌드박스 구성을 참조하세요.
→ macOS 개발시, 샌드박스를 활용하여 개발하기
역자 첨언
Avoid making assumptions about who is signed in. Because of fast user switching, multiple people may be active on the same system.
로그인한 사용자에 대해 가정하지 않습니다. 빠른 사용자 전환을 통해 동일한 시스템에서 여러 사용자가 활성화될 수 있습니다.
→ 다중 사용자 환경을 고려하면서 개발하기
역자 첨언
By default, visionOS uses ARKit algorithms to handle features like persistence, world mapping, segmentation, matting, and environment lighting. These algorithms are always running, allowing apps and games to automatically benefit from ARKit while in the Shared Space.
기본적으로 visionOS는 ARKit 알고리즘을 사용하여 persistence, world mapping, segmentation, matting 및 environment lighting과 같은 기능을 처리합니다. 이러한 알고리즘은 항상 실행되며, 공유 공간에서 ARKit의 이점을 자동으로 활용하도록 앱 및 게임에 허용합니다.
→ visionOS는 ARKit의 알고리즘[ persistence, world mapping, segmentation, matting, environment lighting ]을 항상 실행함
역자 첨언
ARKit doesn’t send data to apps in the Shared Space; to access ARKit APIs, your app must open a Full Space. Additionally, features like Plane Estimation, Scene Reconstruction, Image Anchoring, and Hand Tracking require people’s permission to access any information. For developer guidance, see Setting up access to ARKit data.
ARKit는 Shared Space에서 앱으로 데이터를 보내지 않습니다; ARKit API에 액세스하려면 앱이 Full Space를 열어야 합니다. 또한, Plane Estimation, Scene Reconstruction, Image Anchoring 및 Hand Tracking과 같은 기능은 사람들의 허가를 받아야만 정보에 액세스할 수 있습니다. 개발자 안내는 ARKit 데이터 액세스 설정을 참조하세요.
→ ARKit은 데이터를 앱으로 자동으로 전송하지 않으며 특정 기능에 액세스하기 위해 사용자의 허가를 필요로 함
역자 첨언
In visionOS, user input is private by design. The system automatically displays hover effects when people bring focus to components that you create using SwiftUI or RealityKit, giving people the visual feedback they need without exposing the direction of their gaze before they tap. For guidance, see Focus and selection and Gestures > visionOS.
visionOS에서는 사용자 입력이 기본적으로 개인 정보로 설계되어 있습니다. 시스템은 SwiftUI 또는 RealityKit을 사용하여 만든 구성 요소에 시선을 가져올 때 사람들이 탭하기 전에 그들의 시선 방향을 노출하지 않고도 필요한 시각적 피드백을 자동으로 호버 효과를 통해서 제공합니다. 개발 안내는 포커스 및 선택 및 Gestures > visionOS를 참조하세요.
→ visionOS의 사용자 입력은 개인정보에서 비롯
Developer access to device cameras works differently in visionOS than it does in other platforms. Specifically, the back camera provides blank input and is only available as a compatibility convenience; the front camera provides input for Spatial Personas, but only after people grant their permission. If the iOS or iPadOS app you’re bringing to visionOS includes a feature that needs camera access, remove it or replace it with an option for people to import content instead. For developer guidance, see Checking whether your existing app is compatible with visionOS.
visionOS에서 기기 카메라에 대한 개발자 액세스는 다른 플랫폼과는 다르게 작동합니다. 구체적으로, 후면 카메라는 빈 입력을 제공하며 호환성 편의를 위한 것으로만 사용 가능하며, 전면 카메라는 사람들이 허가를 한 후에만 Spatial Personas에 대한 입력을 제공합니다. iOS 또는 iPadOS 앱을 visionOS로 가져오는 경우 카메라 액세스가 필요한 기능이 포함되어 있다면 제거하거나 사용자가 콘텐츠를 가져올 수 있는 옵션으로 대체하세요. 개발자 안내는 기존 앱이 visionOS와 호환되는지 확인를 참조하세요.
→ visionOS에서의 카메라에 대한 액서스 사항이 다름.
iOS, iPadOS 앱을 visionOS 앱으로 만들 때의 카메라 옵션 사항을 고려하기
역자 첨언
Change Log
작성 날짜 | 작성자 | 수정사항 |
2023/6/20 | 고석준 | 초기 번역 |
2023/12/22 | 고석준 | 배포 |