هل يحتاج تطبيقك إلى شروط خدمة؟

تجد على الإنترنت كثيرًا من الكتابات الواثقة التي تقول إن كلا المتجرين يشترطان شروط خدمة. لكن اقرأ صفحات المتجرين أنفسهما وستجد أنها لا تقول ذلك، لذا يستحق الأمر الفصل بين الأسئلة الثلاثة المختلفة المختبئة داخل هذا السؤال.

هل يشترطها Google Play؟

لا. سياسة User Data في Play محددة بشأن ما يجب ربطه وأين: “All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.” (ترجمة: «يجب على جميع التطبيقات نشر رابط سياسة الخصوصية في الحقل المخصص داخل Play Console، ورابط سياسة الخصوصية أو نصها داخل التطبيق نفسه».) سياسة خصوصية، مرتين. ولا تقول شيئًا عن شروط الخدمة، ولا يوجد في وحدة التحكم حقل لها.

يطلب قسم App content في Play Console رابط سياسة الخصوصية، وإن كان لتطبيقك حسابات، رابط حذف البيانات. والشروط ليست من بينها.

هل تشترطها Apple؟

في حالة واحدة فقط، وهي حالة شائعة: التطبيقات التي تقدّم اشتراكات متجددة تلقائيًا. تشترط الإرشادات 3.1.2 روابط فعّالة إلى كلٍّ من سياسة الخصوصية وTerms of Use (EULA)، داخل التطبيق نفسه وفي البيانات الوصفية (metadata).

لست مضطرًا إلى كتابة اتفاقية EULA تلك. فـ Apple تنشر اتفاقية قياسية ويمكنك ربطها بدلًا من ذلك؛ راجع دليل Terms of Use (EULA) لمعرفة أين يوضع كل إصدار.

وللتطبيق الذي لا اشتراكات فيه، لا تطلب Apple شروطًا أيضًا.

إذن لماذا يملكها كل تطبيق تقريبًا؟

لأن «غير مطلوبة من المتجر» و«لا تحتاج إليها» عبارتان مختلفتان. الشروط هي المستند الذي يجيب عن أسئلة لا تغطيها أي سياسة خصوصية:

• من يحق له استخدام التطبيق، وماذا يحدث عندما يسيء أحدهم استخدامه. بلا شروط، ليس لديك أساس معلن لإغلاق حساب.
• ما تدين به للمستخدم، وما لا تدين به. إخلاءات الضمان وحدود المسؤولية موضعها هنا، وهي سبب وجود الشروط أصلًا.
• ما يدين به المستخدم لك: الدفع، والاستخدام المقبول، والمحتوى الذي يرفعه.
• أي قانون ينطبق وأين يُنظر في النزاعات.
• كيف تتغيّر الشروط، وماذا يحدث إذا كان أحد البنود غير قابل للتنفيذ.

إذا كان لتطبيقك حسابات، أو كان يتقاضى أموالًا، أو يستضيف محتوى المستخدمين، أو فيه أي إشراف على الإطلاق، فهذه أسئلة ستحتاج إلى إجابة عنها في النهاية. وكتابتها قبل النزاع أرخص من كتابتها بعده.

ما الذي ينتمي إلى شروط التطبيق

مجموعة أقسام عملية، بالترتيب الذي تُقرأ به عادةً على أفضل وجه:

القسم	ما الذي يحسمه
استخدام التطبيق	ترخيص استخدامه، والاستخدام المقبول، وما الذي يؤدي إلى إغلاق الحساب
الحسابات	من يحق له التسجيل، وحقك في التعليق، وحق المستخدم في الحذف
المشتريات والاشتراكات	الفوترة، والتجديد، والاسترداد، وأن المتجر، لا أنت، هو من يعالج الدفع
الملكية الفكرية	من يملك التطبيق، ومن يملك ما يرفعه المستخدم
إخلاء المسؤولية وحدودها	جوهر المستند
التغييرات	كيف تحدّث الشروط وكيف يُبلَّغ المستخدمون
الاتصال	عنوان حقيقي

لاحظ ما هو غير موجود: التعامل مع البيانات. فذلك ينتمي إلى سياسة الخصوصية، وتكراره في مستندين هو ما يجعلهما يتناقضان في النهاية.

ما يجب تجنّبه

• نسخ شروط تطبيق آخر مع تغيير الأسماء. إنها مشكلة حقوق نشر، فوق أنها مستند يصف عمل شخص آخر.
• الوعد بما لا تستطيع فعله. شروط تقول إنك تحذف كل البيانات فورًا، أو تضمن وقت التشغيل، أسوأ من الصمت.
• اختيار ولاية قضائية عشوائيًا. القانون الحاكم خيار حقيقي له عواقب حقيقية.
• إخفاؤها. إذا كانت الشروط لا يمكن الوصول إليها إلا من رابط أزلته في آخر إعادة تصميم، فلن تفيدك كثيرًا كوسيلة دفاع.

كتابتها بمساعد ذكاء اصطناعي

سيكتب لك المساعد الشروط بكل سرور، والإخفاق المعتاد هو نفسه كما في سياسة الخصوصية: إذا طلبت منه «شروط خدمة لتطبيقي»، فسيكتب متوسط كل الشروط التي قرأها: بنود تحكيم، ومحكمة في ولاية لم تزرها قط، ووعود بشأن وقت التشغيل. الموجّه (prompt) أدناه يقصره على الأقسام القياسية أعلاه، ويجعله يتحقق مما يفعله تطبيقك فعلًا (تسجيل الدخول، والمشتريات، ومحتوى المستخدمين) قبل الكتابة، ويجعله يضع علامة [confirm: …] على ما لا يعرفه بدلًا من اختلاقه. وإذا كان التطبيق يتقاضى مدفوعات على iOS، فيجب أن يتضمن رابط EULA القياسية من Apple.

انسخه كاملًا. استبدل الحقائق الموضوعة بين أقواس في الأعلى، أو اتركها ودع المساعد يسأل.

You are helping me write the terms of service for my mobile app. They will be published as a web page on AppFoyer, next to the app's privacy policy, and linked from the app and its store listings. They should be short, standard and true for this app.

## About the app

- App name: [app name]
- Developer / company: [developer or company name]
- Support email: [support email]
- Platforms: [Android, iOS or both]
- Store listings: [store listing URLs, or "not listed yet"]
- Where these terms will be published: [your AppFoyer site URL]/terms
- What the app collects, as I declared it: [what the app collects — e.g. account info, analytics, ads, crash reports, location, purchases, or nothing]
- Account deletion page: [your AppFoyer site URL]/account-deletion (only if the app has user accounts)
- Country whose law applies: [country, if you have one]

## Step 1 — find the facts

If you can read this app's source code, read only its build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Info.plist`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file.

From them, work out only what changes the terms:

- whether users sign in or create accounts (Firebase Auth, Sign in with Apple, Google Sign-In and the like);
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like);
- whether users can post, upload or send content that others see (chat, comments, photos, profiles);
- whether the app shows ads or links to third-party services.

Show me that short list with the file each fact came from and ask me to confirm it. If you cannot read the code, ask me these four questions instead.

## Step 2 — ask only what you cannot know

Then ask me, in one short numbered list, and wait for my answers:

1. The minimum age to use the app.
2. Whether the app is free to use for personal purposes only, or also for business use.
3. If users can post content: what is not allowed, and whether I may remove it or close accounts.
4. Anything else you could not determine.

Never guess. Where I do not know an answer, write `[confirm: …]` in the text instead of inventing one.

## Step 3 — write the terms

Sections, in this order, leaving out any that do not apply: Acceptance of these terms · Use of the App · Accounts · Purchases and subscriptions · User content · Intellectual property · Third-party services · Disclaimer and limitation of liability · Termination · Changes to these terms · Governing law (as the placeholder below) · Contact.

- Standard, plain-language terms for a mobile app. Keep each section to a few sentences; this is not a contract negotiation.
- Purchases and subscriptions: payments are processed by the app store, prices are shown before purchase, subscriptions renew automatically until cancelled in the store account settings, refunds follow the store's policy.
- Disclaimer and limitation of liability: the app is provided "as is", and liability is limited "to the extent permitted by law".
- Do not describe how personal data is handled; that is the privacy policy's job.
- Do not promise what I cannot guarantee — uptime, instant deletion, error-free operation.
- Do not invent a company address, a court, arbitration or a jurisdiction — use `[confirm: …]`.
- Do not copy another app's terms.
- Start with `# Terms of Service`, then the line `_Last updated: [today's date]_`.
- Write these placeholders exactly as shown, never the values — they are filled in from my settings when the page is published: `{{app_name}}`, `{{developer_name}}`, `{{support_email}}`, `{{public_url}}`.
- In the Contact section, write the address as `[{{support_email}}](mailto:{{support_email}})`.
- Refer to the privacy policy as `[Privacy Policy]({{public_url}}/privacy)` instead of describing data handling here.
- If the app has user accounts, say in the Accounts section that users can request account deletion at `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)`.
- Mandatory if the app is on iOS and has any in-app purchase or subscription — declared above, found in the build files or confirmed by me: in the Purchases and subscriptions section, include this sentence unchanged: For the iOS version, Apple's standard [Licensed Application End User License Agreement](https://www.apple.com/legal/internet-services/itunes/dev/stdeula/) applies to your use of the App. Never leave it out when the app takes payments.
- For governing law, write the line `{{governing_law}}` on its own and nothing else — it becomes the governing-law section when a country is set in my settings, and disappears when none is.
- End with this paragraph, unchanged:

  _This page was generated from a template provided by the hosting platform and completed by the app developer. It is not legal advice. The developer named above is solely responsible for its accuracy and for complying with the laws that apply to them._

## Format — this is pasted into a Markdown editor

- Reply with the finished terms only, as Markdown inside one ```markdown code block, with nothing before or after it.
- CommonMark only: headings, paragraphs, lists, bold, italics and links. No tables, no HTML, no images, no footnotes.
- Links only to `{{public_url}}` (for example the privacy policy), to Apple's EULA as above and to the support email. Any other link is shown as plain text on the published page, so leave it out. No link shorteners, no download links.

هو مكتوب للصفحات المنشورة على AppFoyer، ولهذا يطلب عناصر نائبة بصيغة {{app_name}} وينتهي بإخلاء المسؤولية الخاص بنا. إذا كنت تنشر في مكان آخر، فاحذف تلك الأسطر في Step 3 واطلب القيم بدلًا منها. ولسياسة الخصوصية، راجع كتابة سياسة الخصوصية بمساعد ذكاء اصطناعي.

ما تفعله AppFoyer هنا

الشروط واحدة من الصفحات الخمس التي نولّدها، إلى جانب سياسة الخصوصية وصفحتي الدعم وحذف الحساب. يغطي القالب الأقسام أعلاه، ويملأ اسم تطبيقك واسم المطوّر وعنوان الدعم وروابط المتجر، ويضيف أقسام الاشتراك، بما فيها رابط EULA القياسية من Apple، عندما تخبره أن التطبيق يبيع اشتراكات على iOS.

ويحتوي محرر الشروط في لوحة التحكم أيضًا على لوحة Write it with your own AI (اكتبها بمساعدك الخاص): الموجّه أعلاه، مملوءًا مسبقًا بتفاصيل تطبيقك. شغّله في أي مساعد، والصق الرد، واقرأ المعاينة، ثم انشر.

تُبقي قائمة التحقق من الامتثال الصفحةَ مُعلَّمة إلى أن تُنشر، وفي تطبيق الاشتراكات، إلى أن يكون رابط EULA موجودًا فعلًا.

وكما في كل صفحة مولَّدة، إنها قالب تكمله وتتحمّل مسؤوليته، وليست استشارة قانونية. إذا كان تطبيقك يتعامل مع المال أو البيانات الصحية أو الأطفال، فاجعل محاميًا يقرؤها.

المصادر الرسمية

• User Data policy — مساعدة Google Play. الاقتباس أعلاه من هذه الصفحة.
• App Store Review Guidelines — Apple. القسم 3.1.2 هو قاعدة الاشتراكات.
• Licensed Application End User License Agreement — اتفاقية EULA القياسية من Apple.