طراحی اپ iOS و ساخت اپلیکیشن iOS برای آیفون و آیپد

اپ iOS من روی آیفون ایرانی چطور نصب می‌شود؟

این اولین سؤالی است که هر خریدار ایرانی باید بپرسد و تقریباً هیچ سایتی صادقانه به آن جواب نمی‌دهد. پاسخ کوتاه: چهار مسیر واقعی برای رساندن یک اپ iOS به دست کاربر آیفون در ایران وجود دارد — انتشار در App Store رسمی از طریق حساب توسعه‌دهندهٔ غیرایرانی، توزیع Enterprise، توزیع Ad-hoc با ثبت UDID دستگاه، و PWA که کاربر مستقیم از Safari نصب می‌کند. هیچ‌کدام بی‌عیب نیستند و هر چهار مسیر ریسک یا محدودیت مشخص خودشان را دارند. انتخاب مسیر، بخشی از نیازسنجی پروژهٔ شماست و پیش از قرارداد دربارهٔ آن حرف می‌زنیم.

چرا اصلاً چنین سؤالی وجود دارد؟ چون به‌دلیل تحریم‌های آمریکا، اپل حساب توسعه‌دهنده برای اشخاص و شرکت‌های ایرانی باز نمی‌کند و این فقط سیاست روی کاغذ نیست: اپل پیش‌تر اپ‌های ایرانی — از جمله یک اپ شناخته‌شدهٔ حمل‌ونقل — را از App Store حذف کرده است. یعنی حتی وقتی اپی از طریق یک حساب غیرایرانی روی App Store می‌رود، ریسک حذف پابرجاست. در طراحی اپ ایفون، این واقعیت را نمی‌شود دور زد؛ فقط می‌شود آن را شناخت و آگاهانه دربارهٔ آن تصمیم گرفت.

در بازار ایران، بیشتر آژانس‌ها این بخش را سکوت می‌کنند و به «انتشار در App Store» به‌عنوان یک بند بدیهی قرارداد اشاره می‌کنند. نتیجه‌اش را ما بارها در تماس‌های ورودی دیده‌ایم: کارفرمایی که پول اپ را داده و در مرحلهٔ انتشار تازه می‌فهمد اپش به دست نیمی از مخاطبانش نمی‌رسد. موضع ما ساده است — این حرف باید روز اول زده شود، نه روز آخر. جدول زیر، همان حرف روز اول است.

طراحی اپ ios یا اپ اندروید — کدام را اول بسازیم؟

پاسخ صادقانه: این را باید از دادهٔ خودتان بپرسید، نه از ما و نه از هیچ مقالهٔ دیگری. سهم کاربران آیفون در میان مخاطبان شما، عددی است که همین امروز و به‌صورت رایگان از آمار سایت فعلی‌تان بیرون می‌آید — گزارش دستگاه و سیستم‌عامل بازدیدکنندگان. اگر بخش معناداری از ترافیک یا خریداران شما از iOS می‌آیند، نبودِ نسخهٔ آیفون یعنی همان بخش از مخاطب به اپ شما دسترسی ندارد. هر عددی که ما بدون دیدن آمار شما بگوییم، حدس است و ما حدس نمی‌فروشیم.

آنچه از واقعیت بازار ایران می‌شود گفت — بدون ادعای عددی — دو نکته است. اول این‌که اندروید سهم بزرگ‌تری از دستگاه‌ها را در اختیار دارد و رسیدن به کاربر اندرویدی از نظر توزیع بسیار ساده‌تر است. دوم این‌که کاربر آیفون در بسیاری از کسب‌وکارها مشتری باارزش‌تری است و نرخ تبدیل بالاتری دارد؛ به‌ویژه در حوزه‌های لوکس، خدمات مالی، سفر، سلامت و محصولات گران‌قیمت. یعنی «سهم کمتر» لزوماً به معنای «ارزش کمتر» نیست و تصمیم‌گیری صرفاً بر مبنای تعداد دستگاه، یک ساده‌سازی گمراه‌کننده است.

همین‌جا یک واقعیت را هم باید بپذیریم: مسیر iOS در ایران سخت‌تر است و همین سختی، خودش بخشی از تصمیم است. اگر بودجهٔ شما فقط برای یک پلتفرم کافی است و مخاطب‌تان عمدتاً اندرویدی است، شروع از اندروید عاقلانه است — و ما همین را می‌گوییم، حتی اگر شما به‌خاطر «طراحی اپ ios» به این صفحه رسیده باشید. اما اگر مخاطب شما آیفون‌محور است، هیچ میان‌بری وجود ندارد جز این‌که مسئلهٔ توزیع iOS را از روز اول و با چشم باز حل کنید.

• سهم واقعی iOS در ترافیک و فروش خودتان را از گزارش آمار سایت بیرون بکشید؛ این تنها عدد قابل اتکاست
• اگر کاربران فعلی‌تان با آیفون خرید می‌کنند، نسخهٔ iOS اولویت دارد — حتی اگر تعدادشان کمتر باشد
• کدپایهٔ چندسکویی، تصمیم «کدام اول» را تا حد زیادی منتفی می‌کند: هر دو خروجی از یک توسعه بیرون می‌آید
• اگر مسیر توزیع iOS برای پروژهٔ شما پرریسک است، نسخهٔ PWA می‌تواند پوشش موقت کاربران آیفون باشد
• ساختن هم‌زمان هر دو پلتفرم بدون بودجهٔ کافی، معمولاً به دو محصول نیمه‌کاره ختم می‌شود، نه یکی کامل

هزینه طراحی اپ ایفون به چه چیزهایی بستگی دارد؟

ساخت اپلیکیشن در برتینا از ۸۰ میلیون تومان شروع می‌شود و قیمت نهایی پس از نیازسنجی اعلام می‌گردد. اما سؤال دقیق‌تر — و مفیدتر — این است: چه چیزی باعث می‌شود همان اپ روی iOS گران‌تر یا ارزان‌تر از نسخهٔ اندرویدش تمام شود؟ چون بخش عمدهٔ هزینهٔ هر اپ (منطق کسب‌وکار، بک‌اند، پنل مدیریت) بین دو پلتفرم مشترک است و آنچه واقعاً قیمت نسخهٔ iOS را جابه‌جا می‌کند، چند عامل مشخص و کاملاً iOS‌محور است که در برآوردها معمولاً پنهان می‌مانند.

اولین و بزرگ‌ترین عامل، مسیر توزیعی است که انتخاب می‌کنید. یک اپ که قرار است از App Store رسمی منتشر شود، باید سختگیرانه‌ترین استانداردهای اپل را برآورده کند: انطباق کامل با راهنمای طراحی، شفافیت کامل دربارهٔ داده‌های جمع‌آوری‌شده، و تحمل چرخهٔ بازبینی که ممکن است چند بار اپ را رد کند و هر بار زمان و کار مهندسی ببرد. همان اپ اگر از مسیر ad-hoc توزیع شود، بار بازبینی ندارد اما بار عملیاتی ثبت دستگاه‌ها را دارد. این‌ها هزینه‌های واقعی‌اند و باید در برآورد دیده شوند، نه بعداً کشف شوند.

عامل دوم، سطح «بومی بودن» تجربه است. یک اپ iOS که صرفاً رابط اندروید را روی آیفون گذاشته، ارزان‌تر ساخته می‌شود اما کاربر آیفون آن را بیگانه حس می‌کند و در بازبینی رسمی اپل هم شانس کمتری دارد. رساندن اپ به سطحی که کاربر آیفون آن را «طبیعی» ببیند — ناوبری درست، ژست‌های آشنا، انیمیشن‌های استاندارد، پشتیبانی از حالت تیره و اندازهٔ متن پویا — کار طراحی و توسعهٔ اضافه می‌خواهد. عامل سوم، آیپد است که در ادامه جداگانه دربارهٔ آن حرف زده‌ایم.

• مسیر توزیع انتخاب‌شده: بار بازبینی App Store، یا بار عملیاتی ثبت UDID در مسیر ad-hoc
• معماری: Native با Swift و SwiftUI در برابر کدپایهٔ مشترک چندسکویی — تفاوت مستقیم در ساعت توسعه
• پشتیبانی از آیپد: چیدمان صفحهٔ بزرگ و حالت افقی، یک آیتم مستقل است و رایگان از نسخهٔ آیفون بیرون نمی‌آید
• عمق انطباق با راهنمای طراحی اپل: هرچه اپ بومی‌تر، ساعت طراحی و پیاده‌سازی بیشتر
• قابلیت‌های اختصاصی پلتفرم: Face ID، Sign in with Apple، ویجت، Universal Links — هرکدام کار جداگانه است
• تست روی دستگاه واقعی: چند مدل آیفون و چند نسخهٔ iOS؛ شبیه‌ساز جای دستگاه واقعی را نمی‌گیرد
• نگهداری پس از انتشار: هر نسخهٔ سالانهٔ iOS یک هزینهٔ قابل پیش‌بینی است — از ۱۰ میلیون تومان در ماه

طراحی اپلیکیشن ios با Swift انجام شود یا با کدپایهٔ چندسکویی؟

پاسخ کوتاه: اگر اپ، محصول اصلی شرکت شماست یا کار سنگینی با سخت‌افزار و گرافیک دارد، Native با Swift و SwiftUI انتخاب درست است؛ اگر اپ ابزار عملیاتی کسب‌وکار شماست و قرار است روی iOS و اندروید هر دو باشد، کدپایهٔ چندسکویی معمولاً تعادل بهتری بین هزینه، زمان و کیفیت می‌دهد. هیچ‌کدام مطلقاً بهتر نیستند؛ هرکدام چیزی می‌گیرند و چیزی می‌دهند.

Swift زبان رسمی اپل است و SwiftUI چارچوب مدرن ساخت رابط کاربری روی آن. مزیت اصلی این مسیر، فاصلهٔ صفر با پلتفرم است: هر قابلیت جدیدی که اپل معرفی می‌کند، از همان روز اول در دسترس است؛ رفتار انیمیشن‌ها، ژست‌ها و اجزای رابط دقیقاً همان چیزی است که کاربر آیفون انتظار دارد؛ و در بازبینی رسمی اپل، اپی که بومی ساخته شده کمتر به مشکل «حس نامأنوس» می‌خورد. هزینه‌اش هم روشن است: اگر نسخهٔ اندروید هم می‌خواهید، عملاً دو پروژه دارید — دو کد، دو تیم‌کار، دو مسیر نگهداری.

کدپایهٔ چندسکویی، همان اپ را با یک بار توسعه به هر دو پلتفرم می‌رساند. برای اپ‌های فروشگاهی، رزروی، سازمانی و باشگاه مشتریان — یعنی بیشتر پروژه‌هایی که به ما می‌رسند — این معماری کاملاً کافی است و بودجه‌ای که آزاد می‌شود، صرف قابلیت‌های بیشتر می‌شود. جایی که این مسیر سقف می‌خورد، سناریوهای سنگین است: پردازش تصویر و ویدئوی زنده، کار مداوم با سنسورها و بلوتوث، بازی، یا اپی که تجربهٔ کاربری‌اش خودش مزیت رقابتی شماست. اگر پروژهٔ شما در آن دسته باشد، همان‌جا و پیش از قرارداد می‌گوییم.

راهنمای طراحی اپل (Human Interface Guidelines) چیست و اپ‌ها چرا رد می‌شوند؟

Human Interface Guidelines — یا به‌اختصار HIG — مجموعه اصولی است که اپل برای طراحی رابط کاربری اپ‌های خود منتشر می‌کند: چطور ناوبری کار کند، دکمه‌ها کجا بنشینند، ژست‌ها چه معنایی بدهند، تایپوگرافی و فاصله‌ها چه باشند و اپ در برابر حالت تیره، اندازهٔ متن پویا و ابزارهای دسترس‌پذیری چطور رفتار کند. اهمیتش دو لایه دارد: یک لایه تجربی (کاربر آیفون به این الگوها عادت کرده و هر انحراف را به‌عنوان «بی‌کیفیتی» می‌خواند) و یک لایه رسمی (در بازبینی App Store، انحراف جدی از این اصول می‌تواند دلیل رد شدن باشد).

اگر پروژهٔ شما از مسیر App Store رسمی پیش می‌رود، باید بدانید که رد شدن، بخش طبیعی و رایج فرایند است — نه نشانهٔ شکست. اپل هر نسخه را پیش از انتشار بررسی می‌کند و شناخته‌شده‌ترین دلایل رد شدن، تکراری و قابل پیش‌بینی‌اند. مهم‌ترین‌شان این است که اپ نباید صرفاً «یک وب‌سایت بسته‌بندی‌شده» باشد؛ اگر اپ ارزش بومی به کاربر اضافه نکند و فقط سایت شما را داخل یک قاب نشان دهد، شانس رد شدنش بالاست. اپ ناقص یا پر از باگ، اپی که مجوزهایی بیشتر از نیاز واقعی‌اش می‌خواهد، و اپی که دربارهٔ دادهٔ جمع‌آوری‌شده شفاف نیست، سه دلیل رایج دیگرند.

یک نکتهٔ تجاری که کارفرماها معمولاً دیر متوجهش می‌شوند: اپل برای فروش محتوا و خدمات دیجیتال داخل اپ، استفاده از سازوکار پرداخت درون‌برنامه‌ای خودش را الزامی می‌داند. یعنی اگر مدل درآمدی شما فروش اشتراک، محتوا یا امکانات دیجیتال داخل اپ است، این قاعده مستقیماً روی مدل کسب‌وکار و حاشیهٔ سود شما اثر می‌گذارد. این را باید در مرحلهٔ نیازسنجی روی میز آورد، نه در مرحلهٔ انتشار. برای کالای فیزیکی و خدمات خارج از اپ، قاعده متفاوت است و در جلسهٔ نیازسنجی دربارهٔ آن دقیق حرف می‌زنیم.

• اپی که فقط سایت را داخل قاب نشان می‌دهد و ارزش بومی ندارد — رایج‌ترین دلیل رد شدن
• اپ ناقص، باگ‌دار یا دارای بخش‌های «به‌زودی» — بازبینی اپل نسخهٔ نیمه‌کاره را نمی‌پذیرد
• درخواست مجوزهایی بیشتر از آنچه اپ واقعاً استفاده می‌کند (دوربین، مخاطبین، موقعیت)
• نبود شفافیت دربارهٔ دادهٔ جمع‌آوری‌شده و نبود سیاست حریم خصوصی در دسترس
• انحراف جدی از الگوهای ناوبری و ژست‌های استاندارد iOS
• نادیده‌گرفتن حالت تیره، اندازهٔ متن پویا و دسترس‌پذیری
• فروش محتوای دیجیتال بدون رعایت قاعدهٔ پرداخت درون‌برنامه‌ای اپل

PWA به‌عنوان مسیر iOS؛ کِی کافی است و کِی نیست؟

بگذارید چیزی بگوییم که به نفع فروش ما نیست: برای بخش قابل‌توجهی از پروژه‌ها، PWA پاسخ درست است و شما لازم نیست برای رسیدن به کاربر آیفون، اپ نیتیو بسازید. PWA یک وب‌اپلیکیشن است که کاربر آیفون از داخل Safari و با «افزودن به صفحهٔ اصلی» روی گوشی‌اش نصب می‌کند؛ آیکون می‌گیرد، تمام‌صفحه باز می‌شود و از نظر کاربر شبیه اپ رفتار می‌کند. مزیت بزرگش در بستر ایران روشن است: نه فروشگاهی در کار است، نه امضایی، نه پروفایلی که باطل شود، و نه بازبینی‌ای که اپ را رد کند. هیچ‌کس نمی‌تواند آن را از دسترس کاربران شما خارج کند.

مزیت دوم، سرعت به‌روزرسانی است. در اپ نیتیو، هر تغییر باید بسته‌بندی و از مسیر توزیع عبور کند و کاربر باید به‌روزرسانی را نصب کند. در PWA، شما امروز تغییر می‌دهید و کاربر همان لحظه نسخهٔ جدید را می‌بیند. برای کسب‌وکاری که قیمت، موجودی یا محتوایش مدام تغییر می‌کند، این تفاوت کوچکی نیست. هزینه هم کمترین است — و اگر سایت شما از قبل روی زیرساخت درستی سوار باشد، بخش زیادی از کار از قبل انجام شده است.

حالا بخش صادقانهٔ ماجرا: PWA روی iOS سقف دارد و این سقف واقعی است، نه تبلیغاتی. دسترسی به سخت‌افزار محدودتر از اپ نیتیو است و نوتیفیکیشن روی iOS به‌اندازهٔ اپ نیتیو قابل اتکا نیست. اگر مدل کسب‌وکار شما به Push Notification برای بازگرداندن کاربر وابسته است — مثل اپ خبری، اپ سفارش غذا یا اپی که کاربر باید از رویدادها فوری باخبر شود — روی PWA حساب باز نکنید. همچنین اگر اپ شما به دوربین و سنسورها به‌شکل عمیق، به کار سنگین آفلاین، یا به تجربهٔ کاملاً روان و بومی نیاز دارد، PWA جواب نمی‌دهد.

• PWA کافی است: کاتالوگ محصول، پنل کاربری، محتوا و رسانه، خدمات مبتنی بر فرم، اعتبارسنجی سریع ایده
• PWA کافی است: وقتی محتوا و قیمت مدام تغییر می‌کند و به‌روزرسانی آنی مزیت است
• PWA کافی است: وقتی می‌خواهید بدون ریسک حذف و ابطال، کاربر آیفون را همین امروز پوشش دهید
• PWA کافی نیست: وقتی Push Notification قابل اتکا، ستون فقرات بازگشت کاربر است
• PWA کافی نیست: وقتی اپ به دوربین، بلوتوث و سنسورها به‌شکل عمیق و مداوم نیاز دارد
• PWA کافی نیست: وقتی کار سنگین آفلاین یا پردازش محلی داده لازم است
• PWA کافی نیست: وقتی حضور در یک فروشگاه اپ، خودش بخشی از اعتبار برند شماست

آیا نسخهٔ آیپد هم لازم است؟

اپ iOS شما روی آیپد اجرا می‌شود — اما «اجرا شدن» با «درست دیده شدن» یکی نیست. اپی که فقط برای آیفون طراحی شده، روی آیپد معمولاً به‌شکل یک ستون باریک وسط صفحه یا تصویری بزرگ‌نمایی‌شده و بی‌قواره ظاهر می‌شود. کاربر آیپد انتظار چیز دیگری دارد: چیدمان چندستونی، استفاده از فضای افقی، Split View برای دیدن فهرست و جزئیات کنار هم، و پشتیبانی از چرخش صفحه. اگر بخشی از کاربران شما آیپد دارند، این یک آیتم مستقل در برآورد است، نه چیزی که رایگان از نسخهٔ آیفون بیرون بیاید.

چه کسانی واقعاً به نسخهٔ آیپد نیاز دارند؟ معمولاً کسب‌وکارهایی که اپ‌شان ابزار کار است، نه سرگرمی: اپ فروش و ثبت سفارش در محل، اپ کارکنان و نمایندگان میدانی، اپ آموزشی و محتوامحور، داشبورد مدیریتی، اپ‌های حوزهٔ سلامت که پزشک یا پرستار با آن کار می‌کند، و هر اپی که کاربر مدت طولانی با آن سر و کار دارد و صفحهٔ بزرگ برایش مزیت است. اگر اپ شما در این دسته نیست، می‌شود نسخهٔ آیپد را به فاز بعدی موکول کرد و بودجه را روی قابلیت‌های ضروری‌تر گذاشت.

تصمیم درست، مثل همیشه، از داده می‌آید نه از سلیقه: آمار سایت فعلی‌تان نشان می‌دهد چه سهمی از بازدید شما از تبلت می‌آید. اگر آن سهم ناچیز است، نسخهٔ آیپد را در فاز اول نسازید — و ما هم پیشنهادش نمی‌کنیم. اگر معنادار است، از همان ابتدا در طراحی دیده شود؛ افزودن نسخهٔ آیپد بعد از اتمام پروژه، همیشه گران‌تر از دیدن آن در طراحی اولیه تمام می‌شود.

هر نسخهٔ جدید iOS چه چیزی را در اپ شما می‌شکند؟

اپل هر سال یک نسخهٔ اصلی جدید از iOS منتشر می‌کند و کاربران آیفون — برخلاف کاربران بسیاری از پلتفرم‌های دیگر — با سرعت بالایی به‌روزرسانی می‌کنند. این یعنی اپ شما ظرف چند هفته پس از انتشار نسخهٔ جدید، عملاً روی سیستم‌عاملی اجرا می‌شود که هنگام ساختش وجود نداشت. نتیجه: اپی که رها شود، خودبه‌خود خراب می‌شود — نه چون بد نوشته شده، بلکه چون زمین زیر پایش تکان خورده است. نگهداری اپ iOS اختیاری نیست؛ هزینهٔ قابل پیش‌بینی نگه‌داشتن سرمایه‌ای است که برای اپ گذاشته‌اید.

آنچه معمولاً می‌شکند، تصادفی نیست و الگوی تکرارشونده دارد. جدول زیر رایج‌ترین این الگوها را کنار کاری که نگهداری باید انجام دهد گذاشته است. اگر قراردادی امضا می‌کنید — با ما یا با هر مجموعهٔ دیگری — این جدول همان چیزی است که باید در بند نگهداری‌اش پوشش داده شده باشد.

• نگهداری در برتینا از ۱۰ میلیون تومان در ماه شروع می‌شود و شرایطش در قرارداد مشخص است
• پایش خطای زنده پس از انتشار، مشکل را پیش از آن‌که کاربر گزارش کند نشان می‌دهد
• زیرساخت سرور و API اپ، با پشتیبانی ۲۴/۷ و آپ‌تایم ۹۹.۹٪ برتینا پایش می‌شود
• افزودن قابلیت جدید، خارج از نگهداری پایه است و برآورد جداگانه دارد

اپ iOS چطور به سایت، پنل مدیریت و CRM وصل می‌شود؟

اپ iOS شما پنجره‌ای به دادهٔ کسب‌وکار شماست، نه یک جزیرهٔ مستقل. در پروژه‌های درست، اپ آیفون از همان API و همان پنل مدیریتی تغذیه می‌کند که سایت استفاده می‌کند: یک محصول، یک قیمت، یک سفارش، یک حقیقت. اگر اپ و سایت دو انبار دادهٔ جداگانه داشته باشند، دیر یا زود موجودی سایت با موجودی اپ نمی‌خواند و آن روز، مشکل شما دیگر فنی نیست — عملیاتی است. به همین دلیل در پروژه‌های سایت و اپلیکیشن، بک‌اند و پنل یک‌بار ساخته می‌شود و هر دو کلاینت از آن می‌خورند.

اما اتصال اپ iOS چند الزام دارد که مخصوص خود این پلتفرم است و اگر سرور برای آن‌ها آماده نباشد، اپ حتی یک بار هم به سرور وصل نمی‌شود. مهم‌ترینشان App Transport Security است: اپل ارتباط رمزنگاری‌نشده را به‌صورت پیش‌فرض مسدود می‌کند، بنابراین سرور باید HTTPS با گواهی معتبر و نسخهٔ به‌روز TLS ارائه دهد. نوتیفیکیشن هم مسیر مخصوص خودش را دارد: روی iOS، پیام‌ها از سرویس APNs اپل عبور می‌کنند و سرور شما باید برای آن پیکربندی شود.

اینجا دقیقاً همان نقطه‌ای است که پروژهٔ اپ در برتینا با یک تیم صرفاً نرم‌افزاری فرق می‌کند: زیرساخت را خودمان داریم و نگه می‌داریم. سرور، دامنه، گواهی SSL و ایمیل سازمانی سرویس‌های خود برتیناست، با بیش از ۲۰ سال سابقه و پشتیبانی تلفنی ۲۴/۷. یعنی وقتی API نیمه‌شب کند می‌شود یا اپ به سرور وصل نمی‌شود، شرکت توسعه‌دهنده و شرکت هاستینگ توپ را در زمین هم نمی‌اندازند؛ یک نقطهٔ پاسخ‌گویی وجود دارد.

• App Transport Security: سرور باید HTTPS با گواهی معتبر و TLS به‌روز داشته باشد، وگرنه اپ اصلاً وصل نمی‌شود
• APNs: سرویس نوتیفیکیشن اپل، با مدیریت توکن دستگاه‌های کاربران و پیکربندی سمت سرور
• Sign in with Apple: در بسیاری از اپ‌ها که ورود با حساب‌های ثالث دارند، ارائهٔ این گزینه انتظار می‌رود
• Keychain: توکن‌های ورود کاربر در حافظهٔ امن دستگاه ذخیره می‌شود، نه در فایل‌های معمولی اپ
• Universal Links: لینک سایت شما مستقیم صفحهٔ متناظر در اپ را باز می‌کند، نه مرورگر
• حالت آفلاین: داده‌های حیاتی روی دستگاه کش می‌شوند و پس از بازگشت شبکه همگام‌سازی می‌شوند
• پنل مدیریت مشترک: محصول، سفارش، کاربر و محتوا از یک نقطه برای سایت و اپ مدیریت می‌شوند

امنیت و حریم خصوصی: چرا انتخاب کانال توزیع یک تصمیم امنیتی است؟

وقتی مسیر رسمی بسته است، اکوسیستم جایگزین شکل می‌گیرد — و اکوسیستم جایگزین، ریسک‌های خودش را دارد. پژوهش دانشگاهی سال ۲۰۲۶ اکوسیستم مارکت‌های iOS ایرانی را «underground» توصیف می‌کند و به سه ریسک واقعی اشاره دارد: باینری‌های دستکاری‌شده، اپ‌های کرک‌شده و ترکینگ ثالث. این را نه برای ترساندن شما می‌نویسیم و نه برای تخطئهٔ مارکت‌ها؛ می‌نویسیم چون خریدار باید بداند که انتخاب کانال توزیع، صرفاً یک تصمیم بازاریابی نیست — یک تصمیم امنیتی است و پیامدهایش دامن برند شما و دادهٔ مشتریان شما را می‌گیرد.

خطر عملی برای شما مشخص است: وقتی اپ شما در فضایی توزیع می‌شود که نسخهٔ دستکاری‌شدهٔ اپ‌ها هم در آن دست‌به‌دست می‌شود، این احتمال وجود دارد که کاربر شما نسخه‌ای را نصب کند که شما نساخته‌اید. اپی با نام و آیکون شما، اما با کد تغییریافته. کاربر تفاوت را نمی‌فهمد و اگر مشکلی پیش بیاید، سراغ برند شما می‌آید، نه سراغ کسی که باینری را دستکاری کرده است. این ریسک را نمی‌شود به صفر رساند، اما می‌شود آن را به‌طور جدی کاهش داد — و طراحی اپ باید از روز اول برای همین کاهش، مهندسی شود.

رویکرد ما این است که اپ نباید به «سالم بودن دستگاه و کانال توزیع» اعتماد کند. اعتبارسنجی نهایی همیشه سمت سرور اتفاق می‌افتد، نه داخل اپ؛ چون کد داخل اپ، در بدترین حالت، در دست کسی است که می‌خواهد آن را تغییر دهد. داده‌های حساس در حافظهٔ امن دستگاه نگه‌داری می‌شوند، ارتباط با سرور رمزنگاری‌شده است و اپ فقط همان مجوزهایی را می‌گیرد که واقعاً استفاده می‌کند. حریم خصوصی هم قاعدهٔ ساده‌ای دارد که تصادفاً همان قاعدهٔ اپل هم هست: هر داده‌ای که جمع نکنید، داده‌ای است که نمی‌تواند نشت کند.

• اعتبارسنجی و اعمال قوانین کسب‌وکار سمت سرور، نه داخل اپ — کد کلاینت قابل دستکاری است
• نگهداری توکن و دادهٔ حساس در حافظهٔ امن دستگاه (Keychain)، نه در فایل‌های ساده
• رمزنگاری کامل ارتباط با سرور و بستن مسیرهای بدون گواهی معتبر
• درخواست حداقلی مجوزها؛ هر مجوز اضافه، هم ریسک است و هم دلیل رد شدن در بازبینی
• شفافیت دربارهٔ داده‌ای که جمع می‌شود، و سیاست حریم خصوصی روی دامنهٔ خودتان
• کنترل کتابخانه‌های ثالث؛ هر SDK تبلیغاتی یا تحلیلی می‌تواند دادهٔ کاربر شما را بیرون بفرستد
• اطلاع‌رسانی روشن به کاربران دربارهٔ کانال رسمی دریافت اپ، تا نسخهٔ دستکاری‌شده نصب نکنند

از ساخت اپلیکیشن iOS دقیقاً چه چیزی تحویل می‌گیرید؟

پیش از امضای هر قراردادی، یک سؤال را از خودتان بپرسید: «اگر فردا رابطه‌ام با این پیمانکار تمام شود، اپ آیفونم با من می‌ماند یا با او؟» در پروژه‌های iOS، پاسخ این سؤال حتی از پروژه‌های اندروید هم حساس‌تر است، چون هویت امضای اپ روی iOS به گواهی‌ها و پروفایل‌هایی گره خورده که ممکن است اصلاً به نام شما نباشند. اگر ندانید آن گواهی‌ها دست کیست، در عمل مالک اپ خودتان نیستید — فقط از آن استفاده می‌کنید.

در برتینا شرایط تحویل به‌صورت صریح در قرارداد می‌آید، نه شفاهی و نه با وعدهٔ «بعداً حل می‌کنیم». آنچه در محدودهٔ تحویل تعریف می‌شود شامل سورس‌کد اپ، سورس بک‌اند و پنل مدیریت، مستندات فنی و راهنمای استقرار، دارایی‌های طراحی (فایل‌های UI، آیکون و اسکرین‌شات‌ها) و وضعیت گواهی‌ها و پروفایل‌های امضاست. جزئیات دقیق هر بند، به دامنهٔ کار و مسیر توزیع انتخاب‌شده بستگی دارد و در پروپوزال مکتوب می‌شود.

اگر می‌خواهید طراحی اپ ایفون‌تان را با ما بررسی کنید، از فرم برآورد شروع کنید یا با ۰۲۱۴۹۱۳۵ تماس بگیرید. برتینا بیش از ۲۰ سال سابقه و بیش از ۱۰۰٬۰۰۰ مشتری دارد، زیرساخت اپ شما را خودش نگه می‌دارد و پشتیبانی تلفنی‌اش ۲۴ ساعته است. اما مهم‌تر از این‌ها، چیزی است که در تمام این صفحه رعایت کرده‌ایم: به شما چیزی را که نمی‌توانیم تضمین کنیم، تضمین نمی‌کنیم. اگر مسیر iOS برای پروژهٔ شما پرریسک باشد، همان جلسهٔ اول می‌گوییم — نه شش ماه بعد و وسط توسعه.

• سورس‌کد اپ iOS و سورس بک‌اند و پنل مدیریت — مطابق شرایط مندرج در قرارداد
• گواهی‌ها و پروفایل‌های امضا: چه کسی مالک آن‌هاست و در پایان پروژه چه اتفاقی برایشان می‌افتد؟
• مستندات فنی، راهنمای استقرار و راهنمای انتشار نسخهٔ بعدی
• دارایی‌های طراحی: فایل‌های رابط کاربری، آیکون اپ و تصاویر فروشگاهی
• دسترسی به سرور، دامنه و دیتابیس — به نام کسب‌وکار شما، نه پیمانکار
• فهرست کتابخانه‌ها و سرویس‌های ثالث به‌کاررفته و هزینهٔ دوره‌ای یا محدودیت لایسنس هرکدام