אנחנו נמצאים לקראת סיום של פיתוח מסנג'ר בוט מתקדם לתחום הכרויות. הבוט מתשאל את המשתמש לגבי פרטים אישיים והעדפות ומציג כל פעם פרופיל אחד, אם הפרופיל מוצא חן בעיני המשתמש הבוט מעדכן את הצד השני וברגע ששני הצדדים אישרו, פותח להם צ'אט לשיחה ישירה.
אם המשתמש לא מרוצה מהפרופיל, הבוט מבקש ממנו פידבק ומציג פרופיל אחר בהתאם לפידבק שהתקבל עד למציאת התאמה.
רצינו לחלוק איתכם תובנות שהצטברו במהלך התהליך:
אל תנסו להמיר את חווית המשתמש מאפלקציה/אתר לבוט - הבוט חי בתוך המסנג'ר עם ממשק טקסט ומספר פקדים לבחירה. אי אפשר לקחת פונקציונליות של אתר מורכב ולדחוף לתוך ממשק מינימליסטי, זה גם לא נדרש. חשבו מחדש על המידע שצריך לעבור ותכננו אותו כשיחה אנושית, כך תדעו לנצל את אחד היתרונות הגדולים שהבוטים נותנים.
תמיד שם בשבילך - נצלו את העובדה שהתקשורת עם הבוט יכולה להפסיק ולהתחדש בכל רגע נתון. כלומר הבוט קלט בקשה מהמשתמש ויעדכן אותו ברגע שתיהיה לו תוצאה. המשתמש לא צריך לחכות לו, הוא חוזר לעיסוקיו האחרים והבוט יעדכן אותו ברגע שיש משהו רלוונטי.אם נסתכל על הדוגמה שלנו המשתמש/משתמשת יכולים לחזור לבוט מתי שהם רוצים ולחפש פרופילים חדשים.
דיאלוג במקום שאלון - עד עכשיו היינו רגילים למילוי שאלונים ארוכים מה שמשאיר טעם מר אצל המשתמש ומזכיר לו מוסדות ביורוקרטיים. הבוט מאפשר לקבל את המידע מהמשתמש תוך כדי דיאלוג כאשר יש לו אפשרות להתאים את השאלות הבאות בהתאם לתשובות שניתנו עד עכשיו. לא עוד שאלונים ארוכים ומייאשים שצריך למלא.
התאמה אישית - בגלל הממשק המינימליסטי של המסנג'ר אל תנסו להציג למשתמש מידע רב שהוא צריך לבחור מתוכו מה שרלוונטי לו (הגישה הרווחת היום באינטרנט). הבוט צריך ללמוד על המשתמש ולהציג כל פעם מספר תוצאות מצומצם שאמורות להתאים לו. אם התוצאות לא מתאימות הבוט יברר עם המשתמש מה הסיבה לכך וידאג להציג תוצאות מתאימות יותר פעם הבאה. כך עם כל צעד הבוט מקדם את המשתמש אל המטרה.
The special panel in this meetup will answer the important question that every entrepreneur and startup need to know before approaching investors and VC’s.
In this meetup, you will learn how to get the attention of investors and potential partners. You will learn from experts how to use two of the most important tools; pitching and public relations.
In this event you will learn the basics knowledge of building Core Bluetooth and building apps.
Most recommended!
We would be happy to meet you there and discuss possibilities of joint work! If you want to schedule a meeting, drop us a line by email: contact@initech.co.il or through the site www.initech.co.il.
כבית תוכנה המתמחה בפיתוח אפלקציות ווב/מובייל/מחשוב לביש, לעיתים קרובות אנו נשאלים על ידי היזמים והסטארט-אפים איתם אנחנו עובדים על שלבי תהליך הפיתוח וההשקה של אפליקציות .
החלטתי לסכם במאמר זה את השלבים העיקריים כדי לעזור ליזמים להבין טוב יותר מה מכיל בתוכו התהליך, מאיזה שלבים הוא בנוי ומהם התוצרים השונים שמתקבלים בסוף כל שלב.
כדי להתחיל בואו נגדיר את גבולות הגזרה שלנו, אנחנו עוסקים בהגדרת ובניית אפלקציות לכן את השלבים של בניית תוכנית עסקית, בחינת השוק ושיווק בכוונה מושארים מחוץ לתמונה.
כמו כן כאשר אני מתייחס לתהליך הפיתוח אני בהחלט לא מתייחס רק לכתיבת קוד(הרי אין מה לעשות עם ערימה של שורות קוד) אלה לכל התהליך הטכנולוגי המאפשר להפוך רעיון כללי לאפלקציה עובדת.
להלן רשימת שלבים עקריים:
הגדרת מוצר – שלב ראשוני זה מטרתו לקבוע את קהל המשתמשים, למפות את הפונקציונאליות של המוצר ואופן יישום המוצר (תוכנה שולחנית, אתר אינטרנט, אפליקציה למובייל או השילוב של כל הנ"ל). התוצר של תהליך זה הינו מסמך טקסט המתעד את כל ההחלטות הנ"ל, דומה באופי וברמת הפירוט לתקציר מנהלים.
אפיון פונקציונאלי – השלב הזה מטרתו לפרט את כל הפונקציונליות של המערכת בצורה ספציפית ומובנת ע"מ לספק את כל המידע הנדרש לפיתוח תוכנה. קיימות מספר שיטות לביצוע אפיון מערכות תוכנה. אנחנו משתמשים בשיטה של פירוק “לסיפורי משתמש”. כל סיפור משתמש מהווה תסריט קצר של פעילות שהמשתמש יכול לבצע במערכת במטרה להשיג תוצאה מסוימת. בנוסף, אנחנו ממפים תהליכי רקע במערכת (תהליכים שמתרחשים בצד שרת ללא תלות בפעולות משתמש). התוצר של תהליך זה הינו מסמך טקסט מפורט המכיל רשימה של כל סיפורי המשתמש והתהליכים.
אפיון חווית משתמש – שלב אשר מטרתו לזהות דרישות של קהל היעד כלפי הממשקים של המוצר ולתרגם דרישות פונקציונאליות שהוגדרו בשלב האפיון לתצוגות המערכת. במסגרת אפיון חוויית המשתמש ייתכנו חידודים ושינויים בסיפורי משתמש. התוצר של השלב הזה הינו רשימה של פרסונות (משתמשים טיפוסיים במערכת), דיאגרמת flows ואוסף wireframes לתצוגות של המערכת.
עיצוב גרפי ומיתוג - שלב במהלכו קובעים את השפה העיצובית של האפלקציה (לוגו, פלטת צבעים, גופנים) ומייצרים עיצובים סופיים לכל אחד מהמסכים של האפליקציה. תוצר סופי של שלב זה: עיצוב סטטי לכל מסך, עיצוב נפרד של רכיבים פונקציונאליים נפרדים בכל המצבים האפשריים, הנחיות למימוש העיצוב ללא צורך בתמונות רקע + תמונות רקע חתוכות עבור אלמנטים שלא ניתנים למימוש באמצעות CSS בלבד.
ארכיטקטורה - תהליך עיצוב התוכנה ובניית תוכנית הפיתוח. זהו השלב האחרון שמכין את הפרויקט לפיתוח, במסגרתו בוחרים טכנולוגיות פיתוח (שפה, חלוקת המערכת לשכבות, ספריות ועוד), מגדירים ממשקים בין רכיבי המערכת, מגדירים ופותרים סיכונים טכנולוגיים. תוצר של שלב זה הוא מסמך המתאר את ההחלטות הטכנולוגיות לפיהן תפותח המערכת וכן משימות פיתוח מפורטות.
פיתוח לפי מיילסטונים- אנחנו עובדים בשיטת פיתוח איטרטיבית(agile development) כל מיילסטון(שלב) מתחלק לתת שלבים דו-שבועיים שבסופם יש תוצרים ברמת גימור ראשונית להציג ללקוח כדי לקבל פידבק פנימי ולתכנן את תכולת תת-שלב הבא. התת שלבים הראשונים מוקצים לבניית תשתית שתתמוך בפיתוח כולו. פיתוח בשלבים מאפשר ללקוח לקבל תוצרים כמעט מהרגע הראשון, להשתמש בהם לקבלת פידבק מקהל המשתמשים ולהכניס את הפידבק למיילסטון הבא. כך אנו דואגים שהאפלקציה המפותחת היא רלוונטית ותואמת את צרכי השוק.
בדיקות תוכנה - ידניות (QA) מקיפות, תיקונים ועליה לאויר - לאחר מספר מיילסטונים פיתוחיים, כאשר אנו מחליטים עם הלקוח שהאפלקציה כבר מכילה את כל הפונקציונליות הנדרשת, מתבצעות בדיקות מקיפות של האפלקציה כדי למצוא תקלות ובעיות שלא התגלו (או שהתגלו אבל לא תועדפו במהלך תהליך הפיתוח). גם כאן מתבצע סינון של התקלות ורק תקלות שלא מאפשרות עליה לאויר מתוקנות וכל האפלקציה נבדקת שנית. לאחר מכן אנחנו מטפלים בהגשת האפלקציה לחנויות, הקמת שרתים לסביבה המבצעית והעלאת מערך ניטור. לאחר קבלת כל האישורים האפלקציה עולה לאויר.
אזי חשבתם שהכל נגמר? לא,הכל רק מתחיל. הרי לא משנה כמה נתכנן השוק הוא זה שקובע! מרגע עליית האפלקציה לאויר מתחיל מחזור החיים האמיתי שלה, כל מה שהתבצע עד עכשיו הם רק ההכנות לקראת שלב זה.
כל פעם שאני נותן מנטורינג לסטארט-אפים במסגרת אחד האקסלרטורי, אני נתקל באתגר הבא:במגבלת זמן של 15-20 דקות אני צריך לספק עצה/משוב משמעותי ליזמים שיושבים מולי. משהו שיעזור להם לקחת את הרעיון קדימה. כאן נשאלת השאלה המרכזית איך מזהים מהם הנקודות הרלוונטיות ביותר שיכולות לקדם את המיזם בשלב זה? היזמים באים לפעמם עם רשימות ארוכות של שאלות ,החל משאלות גלובליות(איך לגייס כסף?) ועד לשאלות פרטניות(האם המסך של האפלקציה נראה טוב?).בדרך כלל סוגי שאלות האלה לא נותנות דחיפה משמעותית לרעיון….
במקרים כאלה אני מציע להם לדמיין שהם מדברים עם יצור אגדי “ג'יני מהבקבוק” שיודע לענות על כל שאלה ומוכן לענות על שלוש שאלות בלבד. למרות היותו יצור אגדי הוא גם מעצבן לפעמים, לכן על שאלות כלליות כגון “ממי לגייס כסף?” הוא עונה תשובות כלליות- “ממשקיעים”. אל תשכחו שיש גם מגבלה של שלוש שאלות בלבד לכן חבל לבזבז אותם על שאלות פרטניות מדי.
לאחר מחשבה מסוימת, עם קצת עזרה מצידי, היזמים מצליחים לנסח את שלושת השאלות הכי כואבות שלהם ומחכים לנס שיקרה. בשלב זה אני נאלץ לבשר להם שאנחנו לא חיים באגדה ואין לי את כל התשובות שבעולם :)
אבל מסתבר שלשאול את השאלות הנכונות זה כבר 50% מהתשובה. אנחנו מנצלים את שארית הזמן לדון בשאלות,חשיבה על פתרונות אפשריים ועל משאבים/אנשים שיכולים לעזור לנו בכך.
אזי פעם הבאה שאתם לא יודעים איך להתקדם אל תחכו לג'יני או אפילו לשעות מנטורינג איתי , תבקשו עצה ממישהו שלא מעורב במיזם אבל מוכן להקשיב ואתם סומכים על האינטלגנציה שלו ותתנו לו לעזור לכם לבחור את השאלות הכואבות ביותר. ברגע שתהיו ממוקדים יהיה הרבה יותר קל למצוא את התשובות.
תזכרו, אם השאלה כללית מדי, יש יותר מדי אפשרויות לתשובות “נכונות” וכנראה זה לא יקדם אותכם לשום מקום. אם השאלה ספציפית מדי , אזי כנראה שהיא לא קריטית וכל פתרון סביר יעבוד, אנשים אוהבים להתמקד בפרטים מבלי לחשוב על ההשפעה שלהם על התמונה הכוללת. למשל, לא מעט סטארט-אפים מתלבטים רבות באיזה טכנולוגיה לבחור ומהי הארכטקטורה שתאפשר להם לעמוד בעומס של מאות אלפי משתמשים לפני שיש להם משתמשים בכלל או שיטה להביא אותם. תזהרו מלהשקיע משאבים באופטמזציה/שיפור של בעיות שעוד לא קרו, יתכן שהם גם לעולם לא יקרו :).
תפקידו של מנטור לתת לכם הכוונה, בזכות זה שהוא ראה חברות רבות בשלבים שונים פותרים מצבים דומים. הוא לא יכול לחסוך לכם עבודת מומחה שישקיע עשרות או מאות שעות בפתרון בעיה פרטנית. אנסה להדגים כמה שאלות שכדאי לשאול מנטור טכנולוגי:
איך לארגן את הRoadmap של המוצר ולנהל את תהליך הפיתוח סביבו?
איזה אנשי צוות וכישורים נדרשים כדי לקדם את הפיתוח הטכנולוגי בשלב נוכחי?
איזה חלקים/שלבים בתהליך הפיתוח כדאי להוציא החוצה ומה צריך להשאר לפיתוח בתוך החברה?
לפי איזה עקרונות לארגן את תהליך הפיתוח כדי שהוא יתאים לשלב הנוכחי?
התובנות האלה הצטברו ממאות פגישות עם לקוחות בית התוכנה שלנו ויזמים באקסלרטורים שונים בארץ ובחו"ל. אני מאחל לכם למצוא את השאלות האמיתיות שיקדמו אותכם קדימה!
We are very excited to share a recommendation video we received from one of our satisfied clients! Watch Dan the CEO of Oggii - IoT start-up in the veterinary field, tells about his experience working with Initech. We are very proud to be part of Oggii’s successful project. More information about Oggii you can find in their website at http://oggii.com If you have an idea for a product or a start-up, you are welcome to contact us contact@initech.co.il or visit our website for more information www.initech.co.il.
This event is dedicated to learn about the Sake, the Japanese rice wine. You will have the opportunity to learn the history of sake, how it is produced, how to drink it and which food to eat with it.
More than 40 companies and investors from Israel and speakers from around the world, will participate in this conference. This is a great opportunity for business networking and learning what the Israeli companies has to offer.
This Meetup is hosting Muriel De Lathouwer the CEO of EVS.com from Belgium.
Most recommended!
We would be happy to meet you there and discuss possibilities of joint work! If you want to schedule a meeting, drop us a line by email: contact@initech.co.il or through the site www.initech.co.il.
כולנו עדים למהפכת התקשורת המתחוללת מול עינינו בעשורים האחרונים. עוד לפני כעשרים שנה אנשים היו מקבלים את רוב המידע/החדשות מעיתונים, רדיו וטלויזיה, ערוצים מאוד חד כיוונים שאין בהם אפשרות לבחור מתי, איך, באיזו צורה ואיזה תוכן נקבל. כלומר לצרכן הסופי הייתה אפס השפעה. החל מסוף שנות התשעים של המאה הקודמת, עם התחזקות האינטרנט וריבוי האתרים, אנשים התחילו לצרוך יותר מידע מהרשת. אתרי אינטרנט איפשרו לצרכן לחפש מידע שרלוונטי לו, להגיב בפורומים וצ'טים, שלא לדבר על העובדה שהמידע היה זמין לו מתי שהוא רצה ולא בהתאם ללוח שידורים קבוע מראש. הופעתן של רשתות חברתיות שינתה עוד יותר את התמונה: אם נחשוב על זה רגע, רשת חברתית לא מספקת תוכן שמנוהל על ידי גורם בודד, אלא מהווה מקום שבו אנשים מחפשים, צורכים ומחליפים מידע בינם לבין עצמם מבלי שיש גוף מרכזי ליצירת תוכן.
התפתחות הסמרטפונים והופעת האפלקציות פתחו עולם חדש של מידע ושירותים מותאמים למיקום הצרכן ואיפשרו להציג מידע/ שירותים במקום ובזמן שהצרכן באמת צריך אותם.
בשנה-שנתיים האחרונות הופיעה תופעה שמחברת את כל הערוצים הדיגיטליים שהצגנו בצורה חדשה לגמרי ופותחת שלל של אפשרויות בהם נוכל לצרוך את המידע ולקבל שירותים, הכוונה לצ'אט בוט.
מהו צ'אט בוט? תוכנה שמאזינה לתוכנת צ'אט שיודעת לקבל ולתקשר עם משתמש אנושי ממש בצורה של שיחה. ברמה הבסיסית כל קונסול שליטה של כל מערכת הפעלה (במיוחד לינוקס) מאפשר לפתוח command line, לתת הוראות למערכת ההפעלה ולקבל מידע. בדרך כלל זאת אפשרות שרק אנשי מקצוע היו מנצלים אותה ורוב המשתמשים העדיפו להתחבא מאחורי ממשק ויזואלי. בשנות האלפיים עם התפתחות מערכות מסחר, שוב הבוטים עלו לכותרות במיוחד בתחום של מסחר במניות ומט"ח. הסוחרים בתחום העדיפו לפתח תוכנה שתדע לקבל פקודות, לעקוב אחרי מצב המסחר (שגם לרוב היה במערכת קונסול) ולבצע את פעולות הקניה והמכירה בהתאם לתנאים שהוגדרו מראש. זה חסך להם המון זמן ואיפשר תגובה מיידית לשינויים של השוק.
בשלוש השנים האחרונות התפתח דור חדש של פלטפורמות מסריים שפתחו את ממשקי המערכת למפתחים ואיפשרו לשלב צ'אט בוטים בתוך הפלטפורמות ולקבל דרכם שירותים ומידע. זה היה שינוי משמעותי לעומת פלרטפורמות מסרים סגורות כגון ווטסאפ, וויבר, פייסבוק, מסנג'ר, סקייפ שהיו עד אז. בין פלטפורמות המסרים החדשות נתמקד במספר דוגמאות :
Slack -פלטפורמת מסרים ארגונית שצומחת בקצב מטורף ושווי השוק שלה מוערך במילארדי דולרים. סלאק שינו לגמרי את התנהלותם של אירגונים רבים וביטלו את תעבורת האימיילים בתוך האירגון. לפני מספר חודשים, סלאק יצאה עם חנות בוטים רשמית ופתחה תשתיות וממשקים כדי שמפתחים חיצונים יוכלו לפתח בוטים בעצמם. היום תוכלו למצוא בוטים שיפתחו את דלת משרדכם,יזמינו פיצה או ינהלו את הוצאות העסק עבורכם.
WeChat-פלטפורמת מסרים סינית סופר פופולארית. פלטפורמה זו מאפשרת למשתמשים לתקשר,לקבל מידע, לבצע קניות ,לצרוך שירותים והכל מתוך הפלטפורמה עצמה עם שילוב של בוטים חכמים.
Telegram - פלטפורמת מסרים פתוחה וחינמית המאפשרת למאות מיליוני משתמשים לתקשר בצורה מאובטחת ולצרוך שירותים. לפני כמעט שנה טלגרם הודיעה על פתיחת הפלטפורמה שלה לפיתוח בוטים.
לאחרונה שמענו גם הכרזות מפייסבוק על פתיחת המסנג'ר למפתחים חיצוניים, דבר זה יאפשר פיתוח בוטים עבורו.
אזי למה תחום פיתוח בוטים נחשב לאחד הטרנדים החמים של 2016?
בוטים מאפשרים לשלב בין עולם הווב ועולם המובייל. הם פועלים על גבי פלטפורמות מסרים ומאפשרים לצרוך שירותים ומידע מותאמים אישית, תוך כדי תקשורת דו כיוונית עם המשתמש בתוך אותה פלטפורמת מסרים שהמשתמש נמצא בה ותוך שימוש נדבך תקשורת ידוע ופופולארי-מסרוני טקסט.
ההתפתחויות הטכנולוגיות בתחום ניתוח שפה מאפשרות להפוך את הדיאלוג הזה ליותר ויותר פתוח (לא מוגבל לפקודות בלבד) וכנראה לא רחוק היום בו נוכל להנחות את הבוטים בשפה אנושית ולכוון אותם לביצוע משימות ומטלות.
מה הם סוגי הבוטים הפופלאריים ביותר בפלטפורמות מסרים?
עוזר אישי וירטואלי- תזכורות, הגדרת משימות ,איסוף דיווחים מחברי צוות.
הזמנת שירותים- הזמנת פיצה, כרטיס טיסה, חדר במלון.
איסוף מידע- איסוף והצגת מידע ממערכות חיצוניות (פיננסי, פרסום, מערכות ניהול) בלי שהמשתמש יהיה צריך לעזוב את הפלטפורמה.
שליטה מרחוק- פתיחת דלתות, ניהול בית חכם, פתיחת דלת מוסך.
לצערי רוב הבוטים מותאמים לשוק בארה"ב ויש מעט יחסית שרלוונטים גם לקהל בארץ. מסיבה זו בחרנו באיניטק להתמקד בתחום זה ב-2016 במטרה להביא שירותים ישראליים מקומים לתוך פלטפורמות המסרים. אנחנו התחלנו עם פיתוחים לסלאק בשלב זה כאשר אנחנו עוקבים בקפידה אחרי התפתחויות עם פייסבוק מסנג'ר כדי להכנס גם לתחום זה. אני פונה לעסקים שמעוניינים להרחיב את קשת השירותים שלהם ולהנגיש את שירותיהם ומוצריהם בערוץ נוסף. תזכרו מהפכת הבוטים מתרחשת בכל מקרה וחבל להשאר מאחור. כנראה שהשפעותיה יהיו לא פחות משמעותיות ממהפכת האפליקציות ולכן כדאי להתכונן לכך מראש.
אתם מוזמנים לצור איתנו קשר באיימל contact@initech.co.il או דרך האתר.
This event connects between Israel and Europe. If you are an Entrepreneur or you have a startup and you wish to meet key people in the German tech and to learn how to tap into the German market, this event is for you.
In this event you will have the opportunity to learn about JFE, the global tech hub that promotes technology and innovation in the jewish and Israeli community worldwide and to learn about the upcoming accelerator in San Francisco.
In this event, you will listen to 3-4 speakers who will share with you their failures, why they failed, what did they learned from the failure and how to succeed despite failing.
Most recommended!
We would be happy to meet you there and discuss possibilities of joint work! If you want to schedule a meeting, drop us a line by email: contact@initech.co.il or through the site www.initech.co.il.
In-App Purchases is often chosen as a main monetization channel for many applications, because of many advantages of the freemium model.
However, correct IAP implementation is notoriously difficult, and Apple are particularly strict in their approval policies for apps that contain IAP.
When you plan on selling anything via your app, you need to determine how does it map to the Apple’s vision of the IAM world:
Consumable
Products that are used one time, after which they become depleted and need to be purchased again, are usually implemented as consumables. For example, fish food in a fishing app could be implemented as a consumable product.
Non-Consumable
Non-consumable products are purchased once by users and do not expire or decrease with use. For example, new race tracks for a game could be implemented as non-consumable products.
Apple can host your non-consumable products for you.
Auto-Renewable Subscription
Auto-renewable subscriptions allow users to purchase dynamic content, such as magazine subscriptions, for a set duration of time. Subscriptions renew automatically unless the user opts out of the renewal. If the content you want offer doesn’t fit what’s outlined in the App Review Guidelines, consider offering the content through a non-renewing subscription.
Auto-renewable subscriptions can include an incentive to customers who share their contact information with you.
Free Subscription
Free subscriptions allow users to download dynamic content, such as magazine subscriptions, for a set duration of time. Free subscriptions are a way for developers to put free content in the Newsstand in the App Store. After a user signs up for a free subscription, the subscription content will be available on all devices associated with the user’s Apple ID. Note that free subscriptions do not expire and can be offered only in Newsstand-enabled apps.
Free subscriptions don’t offer a marketing opt-in incentive as do auto-renewable subscriptions, but users are prompted to share their information.
Free Subscriptions are not available for Mac apps.
Non-Renewing Subscription
Non-renewing subscriptions allow the sale of items with a limited duration. They are used for products that offer time-based access to static content.
If you use non-renewing subscriptions, your app is responsible for delivering the subscription to all devices associated with the user’s Apple ID.
Because a non-renewing subscription requires a user to renew each time the subscription ends, your app must contain code that recognizes when the subscription is due to expire and prompt the user to purchase a new subscription.
One of the particularly obscure distinctions is between the following two product types: Consumable and Auto-Renewable Subscription.
We’d like to share with you our experience of solving a submission problem caused by incorrect usage of product type and a compilation of explanations and examples from real life.
The background story: we developed an application, in which a user is charged a small fee for being able to start a new conversation with another user. The customer wanted to encourage users to pre-pay multiple conversations by offering discount for packages of 5, 10 and more conversations.
We had started out by using “Consumable” type and switched to Non-Renewing Subscription after we got the rejection message from the review board:
“We noticed that your In-App Purchase product was set to an incorrect Purchasability Type.
Specifically, the “Unlock Conversation Token” in app purchase is set to “Consumable”.
“Since the service offered by your application requires the user to make an advance payment to access the content or receive the service, please use the Non-Renewable Subscription In-App Purchase type. Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines.”
We made the change and resubmitted, and got rejected again. This time we got no explanation from the review board, so after many attempts, we were able to arrange a direct conversation with the Apple’s reviewer, which presented us with several options:
Non-Renewing Subscription: give access to all conversations.
Non-Consumable: give access to one conversation without expiration date.
Consumable: purchased once and can be used for purchasing conversation with this “digital coin”.
We choose to use the Consumable purchase type, and finally got approved.
Here’s a compilation of relevant materials that assist to further understand the distinction.
From Apple: “Non-renewable subscriptions. Subscriptions that don’t involve delivering episodic content. Examples include access to a database of historic photos or a collection of flight maps. It’s your app’s responsibility to make the subscription available on all of the user’s devices and to let users restore the purchase. This product type is often used when your users already have an account on your server that you can use to identify them when restoring content. Expiration and the duration of the subscription are also left to your app (or your server) to implement and enforce.
There has been some debates in the comments whether non-renewing subscriptions are consumable or not, so I want to say something about it. "Consumable” means that you can consume them multiple times. Like “30 minutes of talking” in a voice-over-IP telephony application. On the other hand, there are non-consumables that you can buy only once. Like when you unlock all levels in a game app. You buy it once, and when you reset the device and redownload the app, you should be able to restore the purchase, so that you don’t have to pay twice to unlock all levels. Furthermore, if you don’t tap the restore-button in this case but just buy the “unlock all levels” package again, it works, but you will not be charged by apple a second time. That’s why it is called non-consumable. It’s some kind of metaphor. An apple is “consumable”. Once it is consumed, it is gone. A chair is non-consumable. You have it as long as you don’t destroy it or give it away.
So, it makes sense to regard a non-renewing subscription as non-consumable. If you buy it a second time, you shouldn’t pay twice, you should just use the old subscription you already have. If you reset the device, you should be able to restore the subscription once you re-download the app. The restoration is just not done by Apple but by the app itself.
I still regard non-renewing subscriptions as consumable though. I use a simple definition of consumable vs. non-consumable: An in-app-purchase is consumable, when, from the point of view of the StoreKit API, it can be purchased multiple times in the same week by the same user. All consumable IAP-items cannot be restored through the StoreKit. All non-consumable IAP-items can be restored through the StoreKit.
So, the developer is himself responsible for restoring the in-app-purchase of a non-renewing subscription, right? No, sorry. How would the app restore the in-app-purchase of a non-renewing subscription? Suppose I have an iPod and I subscribe to 1 month of listening to the Foo-radio. Now I want to also listen to the Foo-Radio on my iPad. Soo, I install the Foo-App on my iPad and tap the “restore” button. Well… what is the “restore” button supposed to do? How can it know if I already have purchased a “Foo”-subscription or not, and how long it will still be valid? Answer: it can not. This approach does not work.
In order for a non-renewing subscription to work, you have to login the user first, to tie the subscription to some online account. Username/Password, Open-ID, Login via Gmail, Facebook, etc. all would work. Then, when the user purchases an n-r subscription you have to store the fact that he subscribed on some server and link it to his account on the server. You also have to prevent the user from buying the n-r subscription when he is not already logged in. Let’s continue with my iPod/iPad-example above. I download the app on my iPad, I login with Facebook, and voila, I can use the “Foo”-subscription now. There is no need for a “restore” button, because the app should check at login-time which subscriptions the user has.
There will be some additional problems to deal with. (1) For example, nothing prevents the user from logging in into 200 devices. Here the problem is not a user with 200 devices, but a university with 1000 students where 180 students share the same account. (2) If the server crashes, some people will probably lose their subscriptions. Problem (1) can potentially lead to decreased income. Problem (2) can lead to angry and unhappy customers.
Another response from Apple Review Board:
Q: How is the non-renewing subscription being tracked within the app?
A: We send the token id that we get from the store with the user id and the product id to the app’s server and create a purchased item after validating the recipient with Apple’s verify Receipt and checking if the product id is equal to the recipient product id.
After creating the purchased item, we create a chat subscription item with the user id, partner id, the start and end date of the subscription and the purchased item that already been verified with Apple. When the user retrieve his chat subscription, we will him all of his active (by date) chat subscriptions.
So we can’t create a new purchase item on our server without a valid store token that belongs to the right product id and we can’t create a new chat subscription without a valid purchase.
By the way of comparison, in Google Play the In-App Billing there a fewer product types, and they are much less confusing:
Subscriptions
A subscription is a product type offered in In-app Billing that lets you sell content, services, or features to users from inside your app with recurring monthly or annual billing. You can sell subscriptions to almost any type of digital content, from any type of app or game. To understand how subscriptions work, see In-app Billing Subscriptions.
Non-consumable Items
Typically, you would not implement consumption for in-app products that can only be purchased once in your application and provide a permanent benefit. Once purchased, these items will be permanently associated to the user’s Google account. An example of a non-consumable in-app product is a premium upgrade or a level pack.
Consumable items
In contrast, you can implement consumption for items that can be made available for purchase multiple times. Typically, these items provide certain temporary effects. For example, the user’s in-game character might gain life points or gain extra gold coins in their inventory. Dispensing the benefits or effects of the purchased item in your application is called provisioning the in-app product. You are responsible for controlling and tracking how in-app products are provisioned to the users.