Splync v1.5 — پروجیکٹ اور کیٹیگری کے لئے حسب ضرورت خرچ کے تناسب

16 ستمبر 2025 کو Splync v1.5 جاری کیا گیا، یعنی ہماری انٹرنیشنل شادی کی منظوری کے چار دن بعد۔ اس اپ ڈیٹ سے پہلے، Splync خرچ کے تناسب کو حسب ضرورت نہیں کر سکتا تھا؛ ہر خرچ کو برابر تقسیم کیا جاتا تھا۔ v1.5 کے ساتھ، اب صارفین پروجیکٹ اور کیٹیگری دونوں لحاظ سے تناسب کو سیٹ کر سکتے ہیں۔ یہ تبدیلی جوڑوں اور دوستوں کو ان کے حقیقی زندگی کے مطابق خرچ تقسیم کرنے کی اجازت دیتی ہے، نہ کہ صرف 50:50 کی سادگی سے۔ آپ اکتوبر سے روزمرہ کے خرچ کے لئے 60:40 تناسب سے ایک نیا اکاؤنٹنگ پروجیکٹ شروع کر سکتے ہیں، جبکہ اپارٹمنٹ کا کرایہ 50:50 پر رکھ سکتے ہیں اگر یہ آپ دونوں کے لئے منصفانہ محسوس ہوتا ہے۔ اور اگر گروسری 70:30 اور یوٹیلٹیز 62:38 پر زیادہ مناسب محسوس ہوتے ہیں، تو آپ ان تناسب کو الگ الگ سیٹ کر سکتے ہیں — کیٹیگری کے لحاظ سے — ایک ہی پروجیکٹ میں۔

v1.5 میں سب سے نمایاں تبدیلی نیا ممبر اور ڈیفالٹ شئر سیکشن ہے، جہاں آپ پروجیکٹ ممبران شامل کر سکتے ہیں اور ہر شخص کے لئے ایک ڈیفالٹ حصہ مختص کر سکتے ہیں۔ اگر کسی پروجیکٹ میں دو ممبرز ہیں، تو تناسب 50:50، 40:60، یا جو بھی صحیح لگے ہو سکتا ہے۔ تین ممبرز کے ساتھ، یہ 33.33:33.33:33.34، 50:25:25، یا کسی بھی پسندیدہ امتزاج میں ہو سکتا ہے۔ یہ پروجیکٹ کا ڈیفالٹ تقسیم بن جاتا ہے۔ اس کے نیچے، اگر آپ پروجیکٹ کے ڈیفالٹ سے مختلف کرنا چاہتے ہیں تو آپ ہر کیٹیگری کا حصہ ایڈجسٹ کر سکتے ہیں۔ جب آپ کسی کیٹیگری کو حسب ضرورت تناسب دیتے ہیں، تو اس کا نیلا تناسب نشان نارنجی ہو جاتا ہے — ایک چھوٹا بصری اشارہ کہ کیٹیگری اپنی خود کی قاعدہ استعمال کر رہی ہے بجائے پروجیکٹ کے قاعدہ کے۔ یہ تبدیلی پروجیکٹ سیٹنگز کو زیادہ لچکدار بناتی ہے، مگر یہ پروجیکٹ کا نیا/ایڈٹ نظر تھوڑا پیچیدہ بھی بنا دیتی ہے۔ اس میں مدد کے لئے، میں نے ہر سیکشن میں معلوماتی بٹن شامل کئے تاکہ آپ انہیں چھو کر چھوٹے سوال و جواب کے مددگار دیکھ سکیں۔

یہ تبدیلی نافذ کرنا میری توقع سے زیادہ پیچیدہ تھا۔ Splync ہمیشہ 50:50 کی صاف دنیا مانتا تھا — ایک عدد، ہر جگہ لاگو ہوتا، اور حساب ختم ہوتا۔ جب میں نے حسب ضرورت تناسب کی حمایت کرنے کا فیصلہ کیا، تو پوری اندرونی ساخت کو دوبارہ سوچنا پڑا۔ اب پروجیکٹ ایک مشترکہ فیصد پر انحصار نہیں کر سکتا تھا۔ ہر کیٹیگری کو اپنے تناسب کی ضرورت تھی، اور ہر خرچ کو پروجیکٹ کے ڈیفالٹ اور کیٹیگری کی سطح کے تخصیص دونوں کا حوالہ دینا تھا۔ اس کو کام کرنے کے لئے، میں نے بنیادی طور پر حسابی منطق کو دوبارہ لکھا۔ ہر خرچ میں اب ایک چھوٹا فیصلہ درخت ہوتا ہے: "کیا اس کیٹیگری کا اپنا تناسب ہے؟ اگر ہاں تو وہی استعمال کریں۔ اگر نہیں تو پروجیکٹ کا تناسب استعمال کریں۔" جب آپ اسے بیان کرتے ہیں تو یہ سادہ لگتا ہے، مگر ایپ کے ڈیٹا ماڈل کو مستقل رکھنا — iOS ویوز، FastAPI بیکینڈ، اور MariaDB سکیماؤں کے ساتھ — میری توقع سے زیادہ محتاط سیٹنگ کی ضرورت تھی۔

کسی بھی اپ ڈیٹ کو جو سرور سائیڈ کو چھوتی ہے بہت احتیاط سے سنبھالنا ہوتا ہے۔ اگر آپ غلطی سے موجودہ سرور کوڈ کو ترمیم کر لیتے ہیں، تو v1.4 پر موجود صارفین فوراً بگز یا سسٹم ایررز میں پھنس جائیں گے۔ مثال کے طور پر، v1.5 کے لئے سرور پروگرام پروجیکٹ سیٹنگز میں تناسب ڈیٹا شامل ہونے کی توقع کرتا ہے، مگر v1.4 ایپ پروجیکٹ سیٹنگز بغیر کسی تناسب کے بھیجتی ہے۔ جیسے ہی ان دو ورژنز کے درمیان بات چیت کی کوشش ہوتی ہے، درخواست ناکام ہو جاتی ہے — صرف اس لئے کہ وہ مختلف "زبانیں" بولتے ہیں۔ ڈویلپرز، یقیناً، ٹیسٹ ماحول میں تبدیلیاں محفوظ طریقے سے کر سکتے ہیں۔ مشکل حصہ اس وقت شروع ہوتا ہے جب ایک نیا ورژن Apple کے جائزے کے لئے جمع کرایا جاتا ہے جبکہ موجودہ صارفین ابھی بھی v1.4 پر ہیں۔ جمع کرانے سے لے کر ریلیز تک، سرور دونوں ورژنز کی ایک ہی وقت میں حمایت کرنی چاہئے تاکہ Apple کے جائزہ کار v1.5 کو ٹیسٹ کر سکیں اور موجودہ صارفین v1.4 کو بغیر کسی رکاوٹ کے جاری رکھ سکیں۔

ایپ ڈیولپمنٹ میں، ایک "اینڈپوائنٹ" وہ جگہ ہے جہاں ایپ اپنی درخواستیں سرور پر بھیجتی ہے — جیسے شہر کے ہال میں مخصوص کاؤنٹر۔ ایک کاؤنٹر شادی کے رجسٹریشن کو سنبھالتا ہے، دوسرا رہائشی ریکارڈز کو، اور دوسرا پاسپورٹس کو۔ ایپس بھی اسی طرح کام کرتی ہیں: ہر اینڈپوائنٹ ایک مختص شدہ ونڈو ہے جہاں سرور کسی خاص درخواست جیسے لاگ ان، پروجیکٹ تخلیق، خرچ کی تدوین، دوست کی درخواست، وغیرہ کو قبول کرتا ہے۔ جب Splync v1.4 ایک درخواست بھیجتا ہے، تو یہ "پرانی" ونڈو پر جاتا ہے جو پرانے فارمیٹ کو سمجھتا ہے۔ Splync v1.5 اپنی درخواست کو ایک "نئی" ونڈو پر بھیجتا ہے جو تناسب ڈیٹا کو سمجھتی ہے۔ اگر سرور نے پرانی ونڈو کو بہت جلد بند کر دیا، تو v1.4 کے صارفین اپنی ڈیٹا "جمع" کرنے کے لئے کہیں نہیں جائیں گے۔ یہی وجہ ہے کہ، اپ ڈیٹ کے دوران، سرور کو دونوں ونڈو کھلی رکھنی چاہئے — دونوں اینڈپوائنٹس — جب تک ہر صارف محفوظ طریقے سے نئے ورژن پر منتقل نہ ہو جائے۔ سچ کہوں تو، ایک ہی وقت میں ان دو ونڈو کو منیج کرنا ایک اضافی جہت میں سوچنے جیسا محسوس ہوتا ہے۔

Splync v1.5 ہر پروجیکٹ اور کیٹیگری کے لحاظ سے تقسیم کو حسب ضرورت بنا سکتا ہے، مگر ابھی تک ہر خرچ کے لحاظ سے نہیں۔ ہر خرچ کے لحاظ سے تناسب کو سپورٹ کرنے کے لئے، ہمیں ایک اور ساختی پرت کی ضرورت ہے — بنیادی طور پر ہر خرچ کس طرح اپنا حصہ محفوظ کرتا اور حساب کرتا ہے، اس کا ایک گہرا دوبارہ لکھنا۔ ہمیں اس بات کا بھی خیال رکھنا ہوگا کہ ایپ کے انٹرفیس کو اچانک پیچیدہ نہ بنایا جائے صرف طاقت بڑھانے کے لئے۔ یہ سننے سے زیادہ بڑا اپ گریڈ ہے۔ براہ کرم ہمیں وہاں پہنچنے کے لئے تھوڑا اور وقت دیں۔ یہ ہمارے افق پر ہے — اور ہم وہاں پہنچ جائیں گے۔ اس دوران، آئیے دیکھیں کہ نیا پروجیکٹ اور کیٹیگری کے لحاظ سے تناسب پہلے ہی مشترکہ خرچ کو کس قدر لچکدار بناتے ہیں۔